 So, thank you everyone for coming to my session. My name is Jasmine Wang. I'm from a company called Eluxio. So I think this is for community leadership track. So we're going to share about sort of lessons I learned in structuring, building our open source team. So you might find out in this presentation, I probably on and off I would say our open source team or I say our community team. Internally we call the team community team, but you will see later on we have like several functions under this team. So it's kind of interchangeable because I noticed in some other company they call it the DevRel team. They call it open source team, but overall this is the same. All right. So we're going to talk about some metrics that we'll talk about team design, the strategy and then how, you know, we get to decide what kind of metrics we need to report to the upper management. And hopefully, you know, can help to maximize the effectiveness of strategy, help you guys to build it internally, externally. All right. So like I said, I run the community and developer relations team at Olexio. If you're interested in getting in touch with me, that is my email. So here's the rough agenda. We're going to share the experience in me, like I said, personally building this team at Olexio where CRC startup and then defining and then later on defining and building the community growth fly, flywheel and then of course also defining the user types and then diving to the details in the building blocks and the foundations of how you built this team from the scratch and discover some of the resource planning and metrics. Before we go deeper into sort of, you know, how we would build a team, I want to give you a little background of what Olexio does. So you understand why we would take that approach. So of course, we're at open source conference, we're open source project has started at OSU Berkeley's AMP lab. That lab also give birth to Spark. So our project was initially, you know, sort of facilitating Spark back then in 2014. Of course, later on, they also took off on its own, had its commercialized company called Tachyon back then and then we had to change the name for some copyright reason. So it is Olexio. So we have, from a community perspective, we have more than 10,000 people on the Slack channel. That's where people are more active, more than 1,200 people on our GitHub for repo. And then we were named one of the top 10 most critical Java based software. And then the most valuable GitHub repo. So for those of you in case you're a data engineer, you're interested in this product is more of an infrastructure product made for data engineers. You can look into that. I did put our Slack channel link on there if you're interested in checking it out. So what do we do that sort of decide who do we serve, right? So Olexio, this graph shows you what we do as a company other than just an open source company. Now our product sits between the compute engines and then the storage layers. So it's a pretty deep info thing that we're building there. And we do analytics and AIs for hybrid cloud and multi-cloud. So what does that mean? So we serve data regardless of where you take your data from and the storage engine, and then feed it to sort of your compute engines. So we build this layer that sort of help you to virtualize across all of the data sources, and the solution is applicable across environment. So whether it's on cloud, on on-prem, hybrid, multi-barramental, containerized, etc. Now that being said, this is sort of give you a snapshot of what kind of people were used, what kind of companies are using Olexio. Now you notice there's a lot of internet companies like Uber, like Meta, and then Expedia, and etc. But who are really the users using Olexio? They are the data engineer team or the machine learning info engineer, the data platform engineers. So our users, our end users are still highly technical. So this sort of set the tone of how we, when we come in to define our flywheel, you really have to keep that in mind and how you draw those people in. They do have a certain attitude. I think I'm sure each different kind of user has a different set tone and attitude, so we just have to keep that in mind. So those are the companies we serve, but on top of the company, we're usually geared towards what kind of engineer are you serving. This is not a 2C product. We're a B2B business. All right. So now dive into it. Now enough about Olexio. Let's talk about how you structure your team. We always started with there is a bi-directional nature of the open source team. Some information comes in, we also goes out, especially if you're building a dev raw. On the Olexio side, it shares my learning, how we build and design the company, the team. Like I said, we are a series C startup. I've been with a company for about a little more than five years. We do not start actually separating the community team until a little more than three years ago, so end of 2019. So when we first started, it was only two people basically. And then we slowly, slowly build out this function. So that's where we're going to probably go through. So even though I do want to clarify, I personally did not have any hands-on experience in leading a hundred people team at the scale because that's not even a size of our company. You know, our company is about a hundred people, but whether it's for the dev raw team or the community. So we do still have a small list team for between both the community and dev raw and open source engineers. Those are all under us. But nonetheless, I hope some of those philosophers in running such function and how we slowly build it out can lend you some insight for whoever is sitting here today or online is in the process of building or scaling your community team. All right. So that by direction was pretty clear. So usually when it comes to when you hire your first community manager, you tell them what you want them to do. You obviously awareness and adoption, that's only one way, right? We can elaborate a little more on awareness adoption. Awareness and adoption is what you, you stand from the company's perspective, what you want to shoot out. That information goes that way, right? There has to be another way, especially when you start adding the dev raw side. As the information comes in from your users, especially in our case, our users are engineers. They're very active. They're pretty vocal when your product breaks, right? Because they know how to fix it. So we should also need to keep that in mind how you represent sort of open source community, especially the contributors. That's what I mean by two awareness, the by direction. So we can dive a little deeper into that. So awareness adoption is easy to say. What does that mean? I give you a few examples, right? Awareness, for example, evangelizing and educating a Luxio technology. Not exactly the same as today, because I'm not talking exactly about a Luxio, but tomorrow, like me and my colleague has another talk on how do we reduce IO bottleneck in large steel machine learning using our product? That's technical evangelization. That is awareness, targeting exactly the audience that we want to have using our product. Or we can extend awareness to the related ecosystem. What does that mean? For example, two weeks ago, our team published a handbook, that's called Trino Optimization Handbook. For those of you who don't know, Trino is a SQL engine. How is that related to a Luxio? Is it a compute? That's what we serve. But when we have the expertise to serve that related ecosystem, so we also have contributors to that community. So we write a handbook and give it to people for free. So that's sort of extend your awareness to the related ecosystem, because those are your users. Anyone who uses Trino would also use a Luxio. They would read that handbook, they will find it useful. So that's the awareness. We also publish a Presto Optimization Handbook. It's the same thing. That's also a SQL, Presto is also another SQL engine. So what about adoption? Adoption has two dimensions, at least, right? One is breath, how many users, how many people you can gather in your Slack channel on your GitHub, just purely by headcount. Just build your community. Usually those are the job for a community manager or your first manager of the community, whatever you call it. So that scaling should be globally there. If you want to have local community sizes and have events, you want to place them in different time zones. And there's also a depth. What that means is you want to land and expand the Luxio usage in our case in different organizations. What does that mean? Like, for example, earlier I mentioned Uber and Meta uses our product, right? At this point, I do not care. I probably care about outside Uber and Meta if they're another company, like Expedia is also using a Luxio. But if I put an account manager there to look at just Uber and Meta, that depth means I want to know how much penetration we have in Uber, right? How many nodes they have on, right? How many clusters that have run on. How many use cases have already run on Uber. That's the depth. So that's a very different idea than just breadth. So the breadth probably can be reached by your community manager, but when it comes to depth, you do need someone technical. That's probably where your DevRel comes in. That's probably your account manager comes in. We can dive a little deeper later. So that's awareness and adoption. Now the other direction we talk about is user representation. What is user representation mean? So I give a few examples here. This is not the only thing that we do, right? So product validation. What does that mean? Like your DevRel go out and you talk to people and I get some feedbacks. Or the least I can do, I look on a GitHub. I know how many people are filing issues and telling me there's a bug. So it would be my responsibility if I'm the head of DevRel to collect those bugs and then categorize them and provide this feedback to the engineering team. But this is the equivalent if I were the account manager of a certain large account or even smaller account. It is my responsibility to go talk to those people and collect product validation feedback. Your validation should have at least two layers. One is technical validation. Can people even run your code? The other thing is product validation. Can after they run your code, does this still provide enough value that your product claim that you can have for this organization? And those probably going to come through one-on-one conversations. So that's what I mean by product validation. User feedback, of course, there's testing, there's rope mapping. So testing means in our cases, I try to recruit beta users from our larger community. There's, of course, different kind of beta users. Do you want to go more in-depth or do you want to just pick another more smaller scale? Because our products, it's kind of interesting because it can be used as small as like three nodes, three local machines or can be used as large as 10 billion files. So those are really different kind of users as we're trying to recruit there. And that should also be your community's job because your engineers, they won't know. They don't have that direct contact with your community, right? And then that should also be, it also is our job once have a robust to test a community version to feed it to the enterprise version. Oh, that reminds me, I forgot to mention, we do have enterprise offering. So otherwise, we would not survive as a company. So we have two versions in any open source company like us. We offer a community addition. I'm mostly responsible for the open source sites. We do offer the enterprise addition, which they help us to make revenue. Then it would also be at my responsibility if you discover any business opportunity in the community team, you feed it to the business team that go to market. So roadmap, this probably more applicable to your more experienced users. Let's take, well, no, I should not mention their names for more, more experienced users if there are significant contributors from certain organizations. And you do feel like your roadmap should align with the roadmap, or if you're trying to do a more deeper trend penetration in their organization. So you want to collect that user feedback in a more, I would say organized way or well-planned way. So you invite them to even to your roadmap planning discussion. So you know how usually open source is supposed to be one step ahead of the industry or one step ahead of the commercialized product. So you want to explore that and just test if that is actually what the market wants. That's also our responsibility. All right. Now it comes to team explained. I give you like a little idea of what we usually do. There's at least three teams. So I'm going to give this example here, this picture sort of, I'm sure when your organization grows larger, it goes way beyond these three functions. So we talked about community. What is community? Basically it is sort of a non-technical role. They run, they can run incentive programs. They can run meetup and events. They can give people stickers. They're the ones who provide or find venues for the dev roles to advocate basically. Or they may also form partnerships with other ecosystem communities. Like for example, I will go talk to the head in Trinno community or I'll go talk to someone in Presto and be like, let's do something together. Right. So that one, then I will be wearing my community hat. And then they can also build business development. So there's also kinds of in open source is also the BD. So those are the community function. They're purely un-technical. Right. And then of course, then it slowly goes in dev role should be by definition because they're handling developer relations. They should be somewhat technical. For example, they should at least be able to write your Samper starter code. Right. They should be able to answer Q&As on your forum, whether it be on Slack or on GitHub or on Stack Overflow. And then they should be able to, the minimum is to triage those questions and direct it to the right person in your engineering team. So they can dedicate, they can also write dedicated technical content. And then whether it's documentations or tutorials, engineering blogs. So sometimes we will also talk, I noticed that when I my conversation was other community leaders that were like, oh, we're generating blocks. I always have to clarify. Are you talking about engineering blocks? That's for practitioners. Or you're talking about use case blocks. That's for people who don't even know who you are. You just want to sell them. Your product have them a vision. Engineers care about a very different kind of block than your product block. It is DevRel's job to first start with engineering block. That's the engineering practice. All right. And then that's the technical level we'll talk about. That the row should spread from awareness to sort of a minimum adoption that's where DevRel should cover. And then the open source message to help to guide and grow those average users, what we call like normal users. And then you can also include in your DevRel team. It can possibly also include a product manager because those are the ones who are supposed to give product feedback to the product, to the larger product manager team. We can discuss that later as well. And then documentation, educational material if you have your own academy, university, etc. And then that team, the DevRel team should also be geo-distributed spending a 24-hour time zone if your product is meant to be global. Because you don't want to leave a question hanging in your forum without anyone answering within 24 hours. Easy example to give you is we have this on-call system that we for our engineers that they rotate to refer to DevRel to rotate. The requirement is your time for responses within 24 hours. If you pass that, then you failed. Whether you can provide adequate response if you can resolve the question or not within 24 hours, that's another story. But at least you've got to address them. Otherwise, you're not doing the minimum of your job. All right. And then there is also an R&D role, open-source engineering I put there. In some company, they call it open-source software or just community engineering, whatever it is. This is more heavy-ended on the R&D role. You can also put your product manager under here because it's R&D. They sometimes, in our team, they help us to do support online, on-call community support. They definitely are in charge of the release. And then they're definitely in charge of the open-source set of the community road maps, technical road maps, and all of that together with the PM team. This strategy, adopt, how you organize this really heavily depends on your function's lead speciality. The reason why I say that is because after speaking with a few people that are basically all running the same team as I do, we kind of joke about it, you know, to each other. I'm like, you run this this way because you're good at this. It's inevitable that's going to be the case. Whatever I'm good at, that's going to be the first function I built fully. And then I branch out. You slowly recruit your confidant to build out that organization. You can start from there. Of course, there's another way to think about it. Usually, if your company doesn't even have a community team, it is your first one to hire. You kind of need to start with a community manager, fortunately, so you may not have that option. Or if you are lucky, if you can bring in straight a VP open source who has years of experience in the industry, then pass the ball on to him or her and ask her, what do you want to build? How do you want to structure your organization? So that's sort of another way for you to build it out. All right, metrics. So light touch on the metrics. Now we know if we divide it into this, your metrics should be the collective metrics of how you measure each function. Right. And then when it comes to each function, you can also divide it by this is the project KPIs and then got them together. So, but regardless of what overall metrics you have, okay, or you have for any community open source team, I think your GitHub and your community's activities should be a constant measure, regardless of all the other variants. All right. So you notice I don't have a lot of words on my slides. I'm just keep talking. So what does your team covers? I stole the first graph on the left from the DevRel book because I thought it gives a pretty good example of what I say. What does the community do? You were supposed to set up those infrastructure venues so that your DevRel can go do all of the rest of the thing. What is your DevRel supposed to do? They are providing this holistic developer experience and where does that experience come from? Developer education, developer marketing and developer success. Success means you really help them to land whatever they're using your product to. Like whatever problem they're trying to use your product or address, you help them to resolve that. Education is probably we go out and give talks. You know, they can read our blocks and papers and all of that. Marketing is we just go out, evangelizing it or more. You know, so that's pretty. So on the right side is, like I said, all the other functions you need to keep in mind of you're slowly building out, right? If your community team is the one that sits in the middle, then your developer relations, it can be its own function, but it can all be attached to your community in our case, that is. And there's engineering. You cannot live without engineer unfortunately because those are the ones who built the release and the roadmap. So you do have to keep a really good relationship with them. And there's a product side because those are also the one who collaborate with the engineer and to come up with your roadmap. At the same time, product is the one who provides you the idea of what product messaging you're sending out to the community team and probably also to the enterprise team. Those two are usually quite different messengers. And it is also your responsibility to feed to the product of what you hear in the market. There's also the marketing. In my past experience, I want to talk to a lot of other startup founders. When I asked them what's their relationship between your DevRel team and a marketing, I noticed sometimes they don't know. They haven't figured out. So you will see in certain companies this very technical DevRel sits under marketing and has no clue what he or she is going to do. Because they know how to write tutorials and they know how to run code, but the marketing KPIs and OKRs has nothing to do with that. Or you will see a marketing person. They initially hired a DevRel who is not so technical. They put it under marketing. All of a sudden you have a rework and you pull this person under the engineering work. And then now they only have an engineer create letter and then the only thing that's going to happen they're going to quit because there's no way they're going to meet that goal. So ideally, if you're really structuring this, you need to voice to your upper management that this function is pretty cross functional. So our KPI, try not to divide. Try not to have like absolute clear line in the beginning. Just depends on what the person, your sort of employees expertise is and try to design that KPI. Oriented around that OKR. And then to see where it's best to sitting at. Eventually, when I said, remember I said I've been with a company for five years but we did not start the team until three years later. That's how we did it. We start draw people from different teams so that you have a more full function. Instead of you just... So the worst thing going to happen is I've seen a few cases where an engineer is very unhappy under marketing or a marketing specialist is extremely unhappy under engineering. You're just asking them to do the wrong job. All right, community growth flywheel. This is the part I like a lot. I had a talk last year on flywheel, more elaborated. So this will give a very short version of that. First, we got to define user types. There are four different user types in this one I showed you. There's people who discover your product, people who try out your product, people who contribute and people who advocate. Keep in mind that contribution does not have to be code necessary. It can be any other form. They can just be so passionate about it even if they just want to talk about it. That's also contribution. So for any of those type, you've got to keep something in mind, who they are, what this person is, what kind of, like, which category they belong to. What do they want from your community? Are they just curious trying out your product or are they a contributor where they're trying to also get recognized in your community? Or are they to the point as an advocate and super contributor, they're already leading a team in another company using your product and it's their responsibility that they scale even larger, right? And then how do you reach them? That's the communication channel on top of just your regular Slack and Stack Overflow and GitHub, all of that. And what can they do for you? So those are the things you've got to keep in mind. All right, so not under, I'm going to faster speech through this, and then you've got to consider the user journey. So this is probably also something where I can give a meaty session on what this user journey is. You see where the awareness adoption is? So your user journey should go way beyond awareness adoption. I've divided it into seven stages. And so this is when you structure, at least in my case, whenever I structure community or dev route programs, for each program you design, you draw an arrow from where it starts and where it reaches. If all the program lineup together cannot complete this circle, cannot complete this user journey, then you have a hole that you need to fill. That's how we look at it, right? So easy way to look at it. I go out, I talk about Olexio today, we're really only out of awareness because none of you are data engineers. None of you is actually going to consider using this product. So that's where I stop. But tomorrow, if I go and then have that talk on Io bottleneck was machine learning and that if there is an existing user in there, so they might be from evaluation to adoption. Or in another case, when I go to Uber, we discuss where our next roadmap is. We're at expansion stage. Now before expansion, I added retention because this is critical for anyone who has a commercialized product. This would be the same as your customer success journey for the later part. So that's the seven stages. So if you're interested, we can chat about that later. This is how you complete the flywheel. Remember, we talk about those four type of users. How do you complete that? You want your super contributors to sort of help you to raise that awareness so to bring more, you know, members. Now what is flywheel? In case you don't know, it's actually from sort of a concept of the Jim Collins book to go to great. Basically, the idea is your customers are your best salesperson. Then in your community, your super contributors, your biggest advocates, are going to be your best salesperson. If they love your product, they're going to bring more people in. All right. So this is part of the breadth of the community growth, right? We're just counting numbers at the moment. Remember, we'll talk about breadth and the depths. All right. Then the next one. This is just some examples I can flash through. So for example, your super contributors, remember I said, Metta and Uber are using it because there's also cross-community collaboration that can come from cross-community collaboration. If your product or your community is deeply coupled with another product community, then it's, you know, only logically, like we should be partnering with them. Then in this case, for example, you can, you know, originally the Uber's engineer, they're not even using our product and they were not even users in those four grams, right? They start with just new members and discover. But after that whole process, they kind of leapfrog to become super contributors. We have a blog coming out from their engineering team. And then they can also be, you know, help. They would also provide us sort of other communities access when you partnership with some other community. For example, we partner up with Presto, we partner up with Trino. Now those people who are in those communities, now they're aware of Eluxio, right? You can also make new friends. That's always the best thing for people who are also passionate about same similar kind of technology, similar kind of community, you know, the open source kind of community. It's a pretty friendly one, I would say. Talent pool, this is something that's more hidden. Those are also the benefit that you can get. So I'm not going to be shy to talk about it. We did hire a few people from the Presto community when they're a Presto Committer. It helps us as well. So this is also something how you can justify what your community's value is to the company go to market, your saving dollars, considering how much hiring wouldn't usually cost. You can also establish a new playbook when we're talking about depth instead of breadth. So breadth has its own playbook, but each account growth steps should deserve its own playbook as well. So they can help you to later on land different counts and different cases. All right, those are the example. RaptorX is something we built together with Facebook back then, met out right now. And then this is what Uber, as I mentioned, the Uber engineer wrote a block about how they use a luxury local cashier. So that's what you can get from sort of that in-depth penetration, that depth collaboration across community. All right, next one. Building blocks for your open source team. I kind of already covered that, so I'm just going to flash this through since we have to have a few more slides. On top of this, why I identified, I just want to give you a simple reminder. We can add account manager, we can add product manager, technical product manager, technical writer, documentations. You can fine grind all those rows as much as you want, you know, on top of just the three. All right, this is just giving you an example of what I say. In this case, remember, I divided into community, Deborah, and OSS R&D. So brag about what we do, but don't worry about it. So a lot of the numbers you'll see on the upper left, this is what sort of community is supposed to do, right? Remember, you're supposed to reach the breadth, right? We reach how many developers using us, you know, how many meetups you organize, how many countries you go to, you're supposed to be the community manager, supposed to be the one who'll go set up those, so that Deborah can go talk to, right? And then if you look at one on the right, mostly those are what the Deborah else job is, or the OSS R&D's job is. So those are also container metrics at the end of the year, right? On the bottom line, you will see some of the things we highlighted was Uber, that's for R&D, right? Some of the things we highlighted, the roadmap that's definitely was engineered, some of things like we go out to Singapore, and then to have, or Israel to have meetups, that's on community. So those are all the things that you can sort of define at the end of the year when it comes to reporting, right? Cross-community collaboration, I know we talk about this, the same graph came up, but it's going to have different competence. Cross-community collaboration resource, think about the large R&D team should be borrowed for awareness and on call, technical related. So the R&D is probably a little further, and then there's the DevRel, and then your SE, if your organization is big enough, your SE and your SA's should also be involved in your Dev prioritization, because they're also the warriors that's sort of on the front line, right? Just like your DevRels. And then feature, support, account management, release cycle, product messaging, community messaging, all of those needs to be considered when it comes to your cross-team collaboration on the right side. So your developer education, when we're looking on the left side, developer education is with R&D, developer marketing, of course it's with marketing, they're responsible for your outreach channels and the outreach strategy, et cetera. And then there's developer success is mostly with engineering support, customer success, et cetera. So they're responsible for feature, release cycles, lending, and a content gen and a content distribution. Those are two different things. I put notes there, so I want to talk a little bit on that, because I noticed whenever people come to me on Zazenim, we have this new feature that we're going to release, we have this new product we're going to release, what should we do? I'm like, yeah, I'm like, write a block. They're like, okay, I have a block ready. I'm like, what kind of block? It's the same thing, right? Do you have the engineering block? Do you have the use case block? Where's the documentation? I realize most of people, they're confused by content generation and content distribution. Those are very different things. When it comes to content itself, there are probably a spectrum of content you can produce from the most technical to the least technical. Let's go from there. Your documentation should be written by engineer. Your engineer block should be written together by your engineer and your dev rel. And your sample code should be written by your dev rel. Your starter kit should be written by your dev rel. And your tutorial most likely is going to be written by your dev rel, but polished by the marketing, but a community marketing. And your presentation, or mostly should be your community marketing taking out from what dev rel did and packaged up. That's your master presentation deck. Your use case block should be passed on through the product team and working with product marketing team to package up a nice use case block. Those are like at least seven different kind of content we're talking about. Once you have your content lined up, then you talk about distribution channel. So like each block, each kind of content deserves its own kind of distribution channel. And then leave it to the community and a marketing to define where this content should be distributed. All right, resource planning. Last part, I promise you, animatrix. All right. I just put the SaaS funding napkin there for fun. We're not even a SaaS company. So, but the idea is it really depends on the stage of your company. You need to keep in mind the budget, your team size, your responsibilities, and your KPS when it comes to finding your team. So for example, if you're a serious A company, like I said, most like if there's a first time hiring, most likely you want a community manager. It sounds like a small title, but this person needs to give you the first version of the community vision, first version of the strategy and a community and the needs to find a way to build your community platform, whether it's on Stack Overflow, whether it's on GitHub or whether it's on Slack. Then you'll be the first one who start thinking about awareness and user acquisition to reach that breadth. However, if you're a serious B company, you're going to have different asks from the stakeholders, from your board members, also from the upper management team. This is where you start thinking about where's my dev route team, where's my PM, where's my content generator, but I'm a technical content writer, and your acquisition through those content and your developer engagement adoption, those should be what you consider in the serious B. Now, if you're a serious C company, you need to build out that dev route team into more fine grade functions, including account managers, more PMs, and then you also need to come up with the open source go-to-market strategy at this point, because you're a serious C company. Your CEO is guaranteed to come to you, is where does the, where, how do I convert that dollar amount from the community that you're running, right? That talent pool is one way to run it, but you go to market strategy and integration, you can refer back to remember that user journey, you got to find out where you can bring real money to the company, because we know for a fact, in your open source community, there is a pool of candidate who is going to use your enterprise product. You just have to figure that out, how to build that into your project, programs, and feed it to the company. There's retention, expansion, community monetization, it's all happening in serious C or later stage. I only stop at C or C in my discussion here, just because that's the stage we're in. I don't think I should have the expertise in running a pre-IPO company at the moment yet, so hopefully that will lend to your some insights. Last night, this is the user journey I mentioned. I think this is where you, like I said, build out your program under this user journey, all of the program, you align them up, you complete this, no, you're good, right? And then when you think about contributions, to be honest, I put that they're a community, go to market and R&D. This is how I build out. Whenever we build on anything, your goal, your contribution, your goal, the goal of your project is usually pretty evident, but the result of your project needs to serve at least two functions, R&D and go to market. That's just how it is for a C or C company when it comes to that, right? All right, I think that's it, yay. All right, I did have a QR code there just because we usually do a community survey, so if you guys would be so kind and just fill that up, our marketing team will thank me. All right, then I'm open for questions. Do I have time for questions still? Yeah, I do. Okay, cool. All right, if you don't have questions, we can all go early. Do you have tips or insights when the open source project is not owned by the company? Ah, yeah. And how to justify those, the, to the C suite especially, how to justify the budget that needs to go into things rather than them just saying, well, it's free, we can just use it. Let's see where I can probably help you to guess my idea. I'll tell you what I know, like I'm not gonna name the company's name, but yes, there are plenty of company that basically the project is donated to the foundation, right, they build a commercialized company. From what I know from all of my friends who are currently the head of those companies, they run it eventually in the company level. You do need to come up with your own thing. So they are all working on sort of, you can kind of the second kind of product that's based on that, but you're gonna have to write every line of code on your own, but you're kind of just pulling things because open source does not have the same level of support as enterprise. Really, that's the main difference. Or on top of that, you can build out more features, right? So that's more of a R&D product level differentiation, but if you're the head around the community or the dev route team for that, really initially what you can do is advocating for the larger community. You cannot just say I'm only advocating for my company who's wrapping this thing up and selling it. You still need to represent the larger community. So that's mostly what they're all doing. It's been working well in that way because otherwise you're gonna get this big back flashes. We've seen that happen too, so. But from most of what I know is usually after series B, it's almost guaranteed they're gonna start thinking about the deviation of the product. The donation part is still donation. Have you built a SaaS platform? Fortunately, you will have a lot of users, the breadth part you solved. Unfortunately, that means your support team is supporting the entire community other than just your customers. You cannot differentiate who are your users, who are your customers at this point. Yeah. It's a money-burning business though, initially, yeah. I hope that answers. Yes. Thank you for the talk. Do you have any suggestions on user acquisition generally on kind of for a smaller project of just trying to kind of get that initial? Yeah. So if it's a smaller project, you can also mimic that cross-community collaboration one. So you do wanna attach your product to something that's very relevant to you, or you can even go to your competitors' grounds. Let's be honest. We don't do streaming at all, but a lot of streaming are my friends. I went to one of their meet-up to give a talk, and I was like, you can invite your competitors. I was like, oh yeah, they wanna come, they can come, it's fine. Because whoever's gonna use their product is likely they can consider you. So the best way is either a competitor's round or potentially you're serving like your upstream or downstream. So remember I said we produce like Trino Handbook. Trino is like our upstream. It's a tech stack above a Luxio's tech stack. So we keep a very close relationship with them. We produce more materials for the Presto community than the Presto community itself. So a lot of times they would know us, oh, Luxio has Presto expert. We're not even a Presto company. So that's another way to do it. Of course, if you are the creator of your open source project, the best way is you want to be friends with all of the other technical founders of other open source projects, go talk about it. I think people are willing to try it. You do need to find the best audience. Like I said, I understand like today in this talks audience are not gonna be a Luxio users. But tomorrow they're gonna be users. I will always ask them, how many of you have heard about us? What are you using right now? Then you, at least technically, you will understand where you can insert that conversation. So those are more on one-on-one conversations. Yeah, hope that helps. Any more questions? Oh yeah, thank you. No problem. I leave it on this page. I hope this helps. Thank you for the presentation. Actually, I have a couple of questions. I'm trying to phrase it in a way that makes sense, because I'm trying to understand it better. Couple of them. The first one is, so when your developers see the interest of develop some kind of answers and questions in the open source platform, and how do you, I mean, which may or may not align to your budget, your direction of your vision of your company or your team. And also, in that case, we have to kind of leverage. That's one question, how and how much of the freedom you give to your developers to be free, to answer questions in that case. And another question, sorry, I just combined my questions all together. Another thing is, in your diagram of the community of the tree, how you build the community. That's right here. So I'm a little bit confused that in the community that you wanna build, my initial understanding is, it should be a separate team, you know, stand out to kind of socialize with those multiple teams, right? But still, sounds like the engineering team should be part of the community because they're engaged, answers questions. And but now in, I'm kind of trying to understand, in that case, kind of confused me, like are they in the community or not in the community? And also in that case, if they are joining the session, you know, kind of engaged in on the forum to answer those questions, how do you, yeah, part of defining the, how do you define the KPIs? How do you know the time allocation? Yeah. I'll give you an example of a project, how you build it. So yes, to clarify, community should be a standalone on its own. The reason the right side of the graph is like that is you wanna draw expertise from at least those four teams. At least this is the way when I built the foundation, we did hire external people, but when we hire external people, you think about where their expertise lines. We draw, like I was an internal person from a Luxio, there's like less formal community team. So you wanna draw your talent from those four teams. It doesn't mean engineer sits under community. Engineering sits under engineering, period. But they need to contribute to community. So how do you guide them and make sure they do contribute and also make sure they don't run around wild? That's their first question is you need to set up playbooks. So if you're gonna borrow any resource, that is that playbook establishment needs to be between departments. Like I will go talk to the engineer, the RVP of engineer, our chief architect and tell them exactly how many engineer resources I need for exactly what project and this is scope they're gonna cover. They're not gonna go beyond that or if they don't deliver, then their manager's gonna know, right? So on forum, they're also borrowed for that, not just the dev routes. Your engineers, they like to participate in forum to answer questions or to help other people, right? You don't want them to go too far. They need to keep in mind, under engineering, they don't get to solely decide the roadmap. That's when you say like they take too far. That is community's responsibility to pull the product people together with the engineering team. See, this is the roadmap we're gonna stick on. If this fall outside the product that we defined or if you have occasionally annoying person on Slack channel who just really hates you or hates your community, you kick them out. It is the community's responsibility to kick outsiders out. It is also your responsibility to pull the product and engineering together to make sure we are sticking through the roadmap and development. But it is your responsibility to design that schedule for each collaboration. There should be a well-defined timeline with smaller milestones that reach that final milestone. For each milestone, it needs to also have a timeline and a sign-off. So I think where that could deviate is where you really need to make sure people sign off. When they sign off, they cannot go outside that. So don't just make it a verbal conversation. And in my case, I always need their VP of engineering to always sign off and exactly who's gonna do that. A concrete example that I can give you is an on-call rotation. Whether it's a SaaS platform or you have a platform like ours, we don't even have to do 24-7 on-call, but we do an on-call. We borrow engineers and we borrow devrals for those on-call. But the way we look at it is how many resources, how much time I need from them. For example, if I said I need 40 hours of your week, that's one engineer resource that's I'm asking for. Beyond that, I cannot use them. If they are able to solve all those questions within 40 hours, that's great. Then they should reserve the rest of the time helping building that roadmap. That's how I keep them in there. So that agreement is between department instead of between you and a particular engineer. Hope that helps. All right, I think we're out of time. All right, thank you everyone. Let me go to this one, because where's my email? My email. All right.