 Catch my breath. Shall we start? All righty. Welcome, everyone. Thank you for staying until the last day of the conference and coming in person to my session. I really appreciated it. Today, we're going to talk about how we build super contributors in Aluxu open source community. My name is Jasmine. I run the open source effort at Aluxu, and as well as run the developer relations and the developer experiences. So you've seen I put my co-speaker there, even though he couldn't make it here today. I still want to give him a big shout out. He is a founding member engineer and currently serving as the VP of open source. So together, we've built this program. So I do want to recognize his effort, and especially him and his engineering team that he led did put significant effort into the program and some of the project we'll be talking about. Without them, it would not be possible. All right, so here is the outline of this talk. And today, after we provide you a little bit dive into what Aluxu is about, we're going to dive deep into the methodology and framework that we used in building the open source program at Aluxu. And then we will share our experience and how we integrated open source as a key component of the company's go-to-market strategy. Now by building in a flywheel with the super contributors, we were able to build a system such that the community was able to generate growth on its own and a result in ROI that benefit all the departments in the company as a whole. And I'll provide you some example of the super contributors later on. And then of course, we'll also go beyond just the super contributors and share with you some of the other projects we're currently experimenting. And hopefully that will help you when it comes to you building your open source strategy as well. All right, just a little dive so that you guys understand what Aluxu is. A lot of times, you were like, oh, what does it do? So we were actually a research project started from UC Berkeley's AMP Lab back in 2015. And now this has evolved clearly. The open source is still there. And we have about 1,200 GitHub contributors in our open source project and about 9,000 members on their Slack channel. And we're very proud to be named as one of the most critical Java-based open source project by open SSF. And also we're named as one of the most valuable GitHub repository among 96 million of them. So that's a set. Without the community and engineering effort, I would not be standing here today. So of course, I would like to call all of you to join our community to see what we have to offer. If any of you sitting here are online, if you're a community manager and you'd like to exchange ideas, you can always find me on our community Slack channel. Then we can exchange and bounce ideas. All right, so throwback sometimes Same question if you were like, what is Aluxio? But if I mentioned Tachyon, some of them may rain a bell, so that's why I included the slides. So back when it was in the app lab, it's actually called the Tachyon project. It was a research project initially intended to address a specific set of problems by Spark. Some of you might be familiar with Spark. Now it's a company called Databricks. It was actually the same set of people doing research. Spark was about four years older than Aluxio back then it was called Tachyon. So of course, as you could tell, both the companies and the products already evolved since then. Now what is Aluxio today? So today, we built a product that's based on that concept is a large distributed system that is a new layer that sits between the storage systems and your compute engines. And that layer provides you a complete visualization to feed data, to serve data, to applications without worrying about the location of any of your data. And then the solution is also applicable across all environments, whether it is in the cloud, on premise, bare metal, or containerized. So that's what we do. Now there are two versions of Aluxio. As someone will wonder, OK, you're open source company. How do you make money? Of course, just like every open source company, we have an enterprise edition. So the enterprise edition is how we generate revenue. But of course, I'm responsible. And together with our team is for the CE edition, the community edition that's open sourced. Now both of those editions right now, as far as we know, is being used in thousands of organizations. And then we have seen success across verticals with technology company leading the way. And then there's more regulated markets, such as financial services and pharmaceutical companies that would stricter our security needs that they have also adopted Aluxio. All right, that was a dive about what Aluxio is about. You see some good numbers, but it's not always that good. I always have to admit, you know. It was a while, actually, we were a little bit confused when we were also trying to figure out the company strategy. So before 2019, we actually did not have a dedicated community team. Now it's called the ecosystem team, the team that I'm in. Lucky for us, as of 2019, we did found light, like the animation, yeah. So we did found the light in 2019. What that means is, as a company, we've made a decision to include open source as a key component of a go-to-market strategy. What that entails is now the company needs to involve all resources, not all resources, but company resources, to actively build the open source project as well as nurturing the open source community. Now, the decision actually has its merit for those of you who understand when you have a community addition, open source addition, when you have enterprise addition. Of course, the business model of Eluxio is to generate profit and make revenue out of the enterprise addition that we sell. Now, by having a large CE version base, it helps to influence the sales largely and also provides certain level of conversions and which we'll share some examples later. All right, here's where I brag about what we did after we put some dedicated effort into it. I'm very proud of it. So those members were actually from my love letter to the community at the end of 2021. So it's called a year with Eluxio 2021. After, the company has put some dedicated resource into bringing up the community and working on the open source project. We now have community marketing, community event, right, content strategy, a specific playbook for how you can become a member, a contributor, a committer, a PMC member, and even a PFC maintainer. And we track where are the contributions come from and who they contributed and what portion of that is actually significant enough compared to the whole code base. So what we found is, now what we have, just talk about a few projects we have right now, is I run a monthly meetup by monthly, or monthly now, it's getting more frequent now. It's called Eluxio Day. There's a single track, multiple talks. I would invite users to come share their use cases, relative ecosystem open source to share their experiences, collaborations, and our internal Eluxio Core maintainers to share developer engineering progress, and all of that. And we also run another program called Eluxio Product Day that you share product events, right. And then every one of us has already become a technical writer in our company. So we're all contributed to the content strategy. And then I've refined the playbook at how you can make progress as a contributor, from a contributor to a committer and a PMC. I'm glad to say, as of last year, just last year, we were able to promote five PMC members, and one of them also became a PMC maintainer, which is even higher level than a PMC member. And then after we created the committer level, we also promoted two new committers. And as you could see, about one third of the poll request actually came from the new contributors alone. So that's quite significant to us, considering we've been roughly running that program. This was end of 2021, about two years. All right, now I'll give you a good idea of a bragging about my community. How do I do that? We're gonna dive into the meaty part of the conversation where how, you know, share how we, the methodology and the framework that I would in building that program. So when my partner and I had been first started the open source program, we were hoping to find the secret sauce of community growth. So just because of the two of us, we only have limited amount of hours. So the first thing we did is we need to find out who was in our community. Now we did a survey and to see what are the existing members and what is their level of usage? So this is what I found. I found relatively new members. Those are the one who probably heard about Eluxio, read the doc who just joined the Slack channel. And then there are somewhat experienced users. They don't contribute, but they definitely download the community edition and it was tried it out whether it's not on their local machine or at a larger scale. We don't know what extent yet, right? And then of course there are contributors because we can see their code. I tracked their GitHub handles, tell you. So I know who they are. So those are the three profiles found. Now we found those profiles. Our next step, like I said, is we want to build a system such that the community can generate momentum and growth on its own as long as we give the right input. Now in another word, we're trying to build a flywheel out of a community growth. Now the concept of flywheel come from Jim Collins book, Good to Great. Some of you might be aware. The central idea is that your customers are your best salesperson. So if you have happy customers, then they go to tell your friends and you repeat your sales, right? So your business growth then focuses on generating the momentum by leveraging the momentum derived by your happy customer so they can drive more sales, referrals and to repeat that sales. Now how do we adopt that in a community case, right? So now we got to build a community flywheel. What we want is our contributors that we identify the third profile to be our happy customers. So now they can bring more members, users and contributors ideally. Now we realize that it's not happening yet back when we realized that. So that's why it's a dotted line. Now it would be my goal to make that dotted line solid and how will we do that? So when we first track it, I was tracking it by profile, whether you're a new user, you're a contributor, member, user contributor, but I realized that might be a little bit off the track. So if I examine closely based on their activity instead of their member profile, you'll be able to find the missing piece. So the activities we're talking about is when somebody discover your project, most likely that is a new member. And the second step would be, so there are different steps of discovering, right? There's different, I would say different step of activities and different type of activities that we're talking about. One is discovery, one is they try out. So most likely those users start to try out. They're the ones who downloaded. And then the third type contribute, that those are the contributors we found. And then the fourth type would be the one we want as advocate. So that's when we miss. And that's when we want to nurture super contributors that should be a small portion that coming from a contributor pool. Now how do we nurture that? All right. So some of you might already be familiar with this graph. I took it from the DevRel book based on my experience. When we nurture a super contributor a developer having a good developer experience is the key. So I do want to mind you that, so this lists out all the different elements that you might need to take into consideration when you're developing, when you're designing that developer experience we're not going to dive too deep into it. But the one thing I do want to mention is since we're going to share a different profile of different type of super contributors you're going to realize in your community it's not one type of super contributor. You have more than one persona that you're serving. That means you're going to have one more user journey that you're mapping. So one more developer experience that you're designing depends on how many types of super contributors you have or you want to have. All right. So this one is pretty straightforward. It shows you the steps when it comes to, when we first designed the developer experience it sounds pretty simple. So you know, first you look at your contributor tool pool and then to make a survey to see who are those contributors, where you come from, and then you select to them the ones that you want to nurture and then of course you collaborate them. So three steps are pretty straightforward. I'm going to put a little more effort on talking about the second, which is how do you identify and select? I think that might be, you know, it depends on the type of the product that your company is selling. For us we measure three dimension data points for each person that I decide to talk to. We actually did personally talk to a few contributors I hand selected. The first and most importantly is the company they come from. Now this has to do with the type of product that Olexio serves. As you could tell when I described it, it's a large representative layer. The only people who are going to use that are going to be data engineers and infrastructure engineers. We are a B2B business. We serve an enterprise software. So it is important for me to know which company they come from. It is likely that the likelihood of someone becoming a super contributor is more likely so if they come from a bigger company that needs that tech stack instead of someone who's just doing their college homework if you think about it. And then the second dimension of course will be the use case. Why is that important? Because we already have your product and just like our product might already have some well-defined use cases. I want to see when they're deploying Olexio is it expected? If it is, we can let them tips. They can grow faster, right? Or better yet, are they helping us to identify new use cases and going on to new territories that's also in the roadmap where we're going to go? Or in another way, sometimes we'll look at it and we're like, eh, that's not the direction our product want to go. We also want to know. So you want to know what their use case is, right? And then third and more importantly is you, we do pay attention to the individuals because at the end of the day you're talking to a real person, a single contributor, right? So whether this person are working from company A and even if they move to company B they're still going to be a super contributor if they're going to work on the same tech stack. So it's important to care about them. What is their individual goal? What is their personal goal when they're working on this project? And I guarantee you, based on my conversation with a lot of our contributors, they have career goals that we as a community can help them to achieve. So we measure those three dimensions and that's how we hand select a few, I would say profile of the super contributors. All right. So we were very well aware. When I say we integrate open source as part of the go-to-market strategy, we know we will be measured by ROI. All right, so at the end of the day the company's not just gonna give us money to burn the money just to help reach out to the developers and then we're not gonna depleting the engineer resources on my time just because we have so much time in our hands we are still a startup company. So what we want is after putting all those effort we want our positive return of investment. What that means is we wanna be able to whatever the time and hours and a spend or the resources we spend we want that effort to results in it can be new use cases, new users, new revenues and new territories. So that means when we nurture our super contributors we want them to become our champions or they're gonna become a subject expert or they will be the tech lead in that area and in better yet they can be an economic buyer and so much more. So we're gonna go through four examples like I said specifically was different kinds of super contributors and ROI from those. All right, take a quick break. First kind. We call them special interest groups led by the super contributor. Now what are special interest groups? So as we observe the contributors they start working with Alexio in breadth and depths. They actually like working together if we're working on the same topic and it helped them to make faster progress. So when running a community we take it upon ourself to form what we call special interest groups by subject. So then so they can have bi-weekly or weekly syncs whether it's on issues, features, roadmaps, bugs, optimizations and everything you can imagine on the engineering workload. So provide them this space and soil so that they can get together and have that discussion. Right, and then for example, so this slide is actually a given example of the special interest group I've run before. This is led by a project led by Microsoft, Alibaba and then 19 University of course it was a few engineers on Alexio core maintainers and then they were investigating a deep learning workloads on Alexio. So we formed a special interest group on a working on that specific territory. I can tell you the ROI, so if you're more interested in the project later I always provided the link in these slides, you can download and take a look at it. The ROI from this super contributor case, one is we actually expanded our ecosystem. We give birth to another open source project based on this collaboration that is called Fluid Project of your interest in checking in. And as two, we expand our new use cases. We pioneered a machine learning and deep learning use case scenario for Alexio that we do not know that could work so well. And then third, importantly, at every time when you wrap up a process we establish a new process playbook for how you assemble a special interest group and pick your leads and have them work together. So now that playbook is being applied in some of our new initiatives with the new special interest group that we've kicked off. So I'm glad to say we've just recently kicked off another special interest group in running Presto on Alexio. And then that has kicked off the community sync bi-weekly as well. If any one of you run those workloads, feel free to tap in. It's always, you know, all the information is on our GitHub Wiki. And then it was engineers actually leading the effort from Tencent, Robinhood and a couple from our team as well. All right, here's the second example. So we first mentioned the special interest group. I did say Presto, but actually the collaboration between the Presto community and the Alexio community goes back before we even formed the open source team. So that's what I wanna mention, the cross community collaboration. We found that's very important and it plays a significant role in how we were actually able to form our own team and then learn our lessons. So the collaboration, like I said, back then, this is before 2019, right? When I said we formed a real team. And then Facebook back then and Facebook's Presto team now met us team, they let the effort into kicking off this initial collaboration. So together we built a project called Raptor X. If you're interested, I'll include a link there since that's more on the technical side. Just feel free to check it out later. And then so the ROI that we got from this cross community collaboration is one, those Presto committer, they went from non-users and leapfrogged to be the super contributors. That is something we do not expect from progress, right? So that's a great news to us. And two, we were able to tap into a top tier community, observe how they run their open source project as well as given access to their Presto committers. So that was a good plus for us, a learning lesson. And three, we're able to make some new friends and all those friends are technically strong. And then of course they're very passionate about working in open source. And then four, if any one of you is an engineer manager, you're gonna like that. We had a talent pool that we tapped into and I'm very glad to say I was able to recruit a few of the Presto community members in my current team at the moment. So on five, just like the previous one, whenever you wrap up a whole process, we did generate a process playbook in terms of the cross community collaboration. And now we're referencing that playbook in our new collaborations between Olexio and Uber and Olexio and TikTok. All right, a third example. If the first two sounds like it might be a little long winded or you need to put a lot more engineering effort to it, the third one I guarantee you as just even of a non-technical community manager, you can do it on your own by just giving a little more support on your side is your PMC members. So those are your project management committee members by definition, those are your subject expert, they are strong technically, they have already been using your product, they probably already advocated before you even know it. And so what you want to do is to give them just enough resource, just enough support so that you can enable them to help you to adopt, refine, and scale Olexio's deployment in their environment or in other companies. And then of course those people will be able to give you critical product feedback at a scale that is only possible in a few leading companies in our industry. And then the individuals, they're also strong engineer outputs that we've seen those PMC members leading specific features in a release as you can always encourage them to do that. All you need to do is include them in your roadmap, in your engineer roadmap. And of course you can always host joint open source event with them and you'll be able to generate high quality content coming from that event and share it with a greater open source community. All right, last example of a super contributor, like I promised, they do convert into a economic buyer. So it does happen. I know sometimes it take a little longer time. So what we found significant is developer education is quite the key here. So you need to let that particular contributor be well aware, your super contributor be well aware of the difference between your community addition, the open source one, and your E-edition, your enterprise version that you're selling. And then as a product owner, of course it will be your responsibility to have well-defined features that differentiate those product, right? And then all it takes is time and an opportunity and then you're just next to them. And the ROI, of course, from that super contributor is immediate revenue gain for your company. But at the same time, you will have an insider coming from the community, being your champion after the service is made. Alrighty, so good. Now that we've closed the loop. I've given you a flywheel and we'll close the loop and give you some examples and hopefully you can take those examples home and build it into your community strategy. It's all great so far, but I would recommend let's not stop there because you gotta keep digesting your flywheel. You gotta tune it. Now why do we tune it? Because your resource is limited, right? And both your internal open source team, the ecosystem team, and your community is growing. Those are evolving over time so your strategy gotta evolve too. And also, your output metrics might be changing over time too. So what should you tune, given that? We tune the input actions so that you can match the output metrics that you desire, right? So you reallocate the effort and the resource that you input. Now how do you do that? All right, by going beyond super contributors for sure. So I give you a few examples on how do we do that. So I mentioned the evolving team makeup and project. So what do I mean by that? Recall when I said, when we build the open source into a key component of go-to-market strategy, we understand that the goal is to benefit the company as a whole for each department, right? So then you can adjust the team makeup and as well as the project you do, based on what is that output you want. Let me give you an example. For example, let's say we're lacking content from the marketing perspective, especially engineering content, then what do we do? You tune up your community event. You tune up your community marketing and you tune up your blog writing, right? The content strategy, then you change that so you provide them high quality content. When your product needs feedback, you can even temporarily add a dedicated person on your open source team, act like the open source product manager to provide a one-to-one feedback to your product team. And of course, on the sales side, you should always keep an eye out to see who are the possible economic buyers to turn into, but even you don't see those, you should always provide them the large base of influence, like we said, and then the insights that you'll learn from the community. And of course, because we also have an engineering team in the ecosystem, so the engineering team does collaborate and there's always some joint development going on between this team and then the larger engineering team. So that's how you want to tune based on different teams' needs. And then another example is that we designed an internal system that tracks contributions. I highly encourage, if you haven't done so yet in your community, you got to start tracking things. I remember I was asking John how you track your stuff. So that's why I said I had to hand design that because I look into other tools. I'm like, that's not applicable to my community, unfortunately. But it does lend me insight. You got to track it. The best way for me to track, I look at the scores. I design a score system on ML and then we implement that. It's only for internal, but just by looking at that, you know where you fell short, where you did well. So then you adjust it, right? So you need to have that system in place so that even when you're communicating internally with either team, you can justify it where you input action. And then the third, you can also adapt and adopt a localized strategy. This is more applicable to teams that are more distributed or they have different communities in different countries, I would say, in locations. For example, we do have a pretty vibrant Chinese community and they're Chinese speaking. They're also located in a different time zone. So we have a dedicated open source team there in China that that team is recently experimenting with a gamification system that they're working on. It's a sort of like experimental marketing with a face in the developers. And then the goal is to generate some quick wings so that they can provide timely reward and then satisfaction for those developers who want to participate. So it kind of function like a loyalty program. So that's like the small incentives, all right? So those are the house and how you tune your flywheel. All right, hopefully we're on time, good. All right, the takeaways. Finally, we get there. I want to remind you, an ecosystem is a multi-dimensional team. So when forming your team, you got to think about what you could provide, the feedback to each department, the company as a whole, right? If you're currently forming your open source strategy, I do hope after this talk, you can go define your flywheel, find the missing piece, discover your super users and go keep tuning your flywheel until you make it right and then tune it again when your organization grows. All righty, thank you very much for those of you online that tuned in and for those of you who showed up in person on the last day. I do like to invite you to again, check out our website, we are smart startup, but I do believe the engineer work that putting there is quite solid. So I've been there for five years for a good reason. Join our Slack channel too. And if you're a community manager, like I said, or you've a dev drill person, you're more than welcome to come talk to me, exchange name cards, like I said, we do host a bi-monthly and monthly event and I'm sure you do that too. We can always exchange our talks and I would love to share some ideas and bounce how we build our community in each and our own. And I do want you to follow us on social media. My sincere apology, I forgot to put my own LinkedIn on there because I had the marketing team help me to make the last page. And feel free to add me on your LinkedIn. My name is Jasmine Wang, first name, like the flower, last name, W-A-N-G. Actually sounds like wang, that's how you pronounce it in Chinese. And if you type Jasmine Wang, you'll be able to find me on LinkedIn. Do connect with me and let's chat afterwards. All right, that's my talk today. I think I spoke a little fast, but I'm ready for any question if you have some. Yes. We do have one online question coming from Tim. It says, so you are only going to mentor select users, talent that is committed to chosen project that you have selected as a company. No, actually, we're not just a mentoring though, thank you, Tim, first of all. So when I say picking super contributors, that's more like a project base, as you noticed when I say. The mentoring actually, it's not one-on-one mentoring, but the reason that a Slack channel exists, that we have a general channel, we have all the DevOps, and there's a lot of different subject in the Slack channel, is so that we have the whole community that help, that's the whole point of open source. So it doesn't mean this person does not get any mentorship just because you're not a super contributor, right? There is actually a pretty well-refined book on how you contribute to the Luxio open source, and then there are introduction level tasks, they're media level tasks, because they're high level, difficult level tasks, so we have already designed all those curriculum, so that's how by step, by step, you can actually just climb the ladder on your own, and if you have questions, anyone can always ask them on the Slack community, that's where we engage some, we welcome this discussions there, but when we're talking about super contributors, yes, it does fall onto an individual, because those individuals might be the tech lead of a specific company, so we do have to focus on that, but I wouldn't say that relationship is mentoring, I would say sometimes we learn so much from those people, it's more of each super contributor is more like a nurturing and collaborating, we get so much more feedback from those people. So if you are looking for mentorship in open source community, I think pretty much every matured open source project would have those beginner tasks, if you're interested, you can always check, we have marked them beginner, medium, and difficult, and try them out, and then they're also listed on the doc page and how you actually start boosting up a cluster on your local machine, yeah. There's another gentleman in the back, yeah, go ahead. No, no, no. No, you actually answered one of mine, but the other one was, when you finally, and you mentioned this, I apologize, I missed it, when you finally say, okay, this is a super contributor, do they approach you or do you approach them or how, those two examples you have, who approaches you? Good question, so we give you four examples. So in our conversation, we never just call them, hey, we identify as a super contributor, this just sounds very awkward, right? So I give you four examples, one of them is the first is special interest group, right? So in that case, we actually don't tell anyone that you are a super contributor, it's more of a process we're hoping that by forming a special interest group, those people with enough contributions, they're gonna become a super contributors. Like I said, we do have a point system, I monitor to see how much contribution they're putting, so it's more like in my backlog, I know whether you've become one or not, but in another case, like the Presto team and a Facebook back then case, they approached us, right? They were using our open source product, so they came to us and then they actually approached my partner Ben and specifically asked for him for his collaboration. So in that case, it's kind of, they voluntarily become super contributor because they want to learn more about our tech stack so they can integrate in their product. And then, I guess I also give another case of the PMC, so in that case, that's more volunteer on a personal base, like by the time we found them, they're already the project management committee, so even before we know. So those people, we're glad to have them, those are more organic, but the economic buyer though, we do approach them, so the way that is, I'm just going through example by example, so it's more clear, so economic buyer, you always know, when you profile those contributors, not even the super contributors, we know actually as a company as a product, you kind of know which sector will need enterprise addition, but they're not using it, right? So in your conversation with those people, you kind of know at what point will be that break point, so you kind of keep on having those frequent conversation and went until that moment happened, so it's kind of always both ways, it depends on which profile we're targeting. Yeah, thank you, Vinay? Yeah, contributors, yeah. Yeah, good question. Yeah, so we are, and I don't mind saying, you guys can find that on CrunchBase too, we are seriously startup with about 100 people, so it's hard to imagine not all of us are engineers, so I wouldn't say it's on the support side, so when they're the contributors, and we do need to support, but it's not, I would say, we're not 24 seven support from the open source perspective because that's not the goal for open source, that we want people to contribute, so the enterprise addition, of course, is another story that they get dedicated support. I would say among those contributors, PMC member, we probably have about 30, 40 PMC members right now, so those are all subject experts, so those people can full-on answer a lot of questions and represent the Alexio open source among those people, and then the second tier is the committers, we have quite a few of them, and of course we have own core maintainer in-house, and then actually, some people, even if they didn't make it to the committer level, if they've been using Alexio, we have quite a strict criteria for committer and PMC, so if they've been using Alexio in their environment, they already become a subject expert, so they do help to answer a lot of questions in GitHub on Slack channels, excuse me, yeah. Yeah, the engagement, so the whole goal, like I said, building that flywheel is we want that to generate on its own, so yeah. Yeah, thank you, oh yeah, go ahead. I have a question, you mentioned that one of the products or byproducts of a crane that was a separate product or something of that nature was born, I'm curious about what exactly do you do to nurture and foster these special interest groups, do you set a certain theme, how do you guide it to let that community grow in this direction that it's also conducive to the product, and then how do you also, and there's your other pathways of like, that could take, that could arise from those relationships that are built. So for a special interest group, yeah, good question. So when that project was born, that was actually the first special interest group that were formed together, and we were also lucky because those people who were leading the effort from Microsoft, Alibaba, and Nike University, they all come from a pretty heavily researched background and technically very sound engineers, so by engaging with them, we realized that sort of a four-party together have the capability of exploring a new territory, so you kind of have to understand it's always good to know your own capability to see whether you can tackle that. Once we know we can tackle a new territory, that's when we decide how much resource to put. Actually, it's the four different parties together decide how often we meet, what is the roadmap for that specific thing that we're trying to do, and then actually it then, it took it to the next level because initially you're just trying to deploy Alexio for a deep learning use case, a workload, but then you realize you can build so much more on top of it, including like giving birth to a new project that has to do with us integrating different tech stack together and maybe we want to package it up, so that was actually led by the Alibaba and Nike University group, they're like, we want to kick off another open source, what do you guys think? We're like, great, why not? Yeah, so there is a lot of conversation happening, so that kind of chime back to the super contributor. It does take a lot, like that's what I said, there is, that's why resource allocation is important, you got to keep that in mind. Think about what's your team's capability capacity and then think about how much resource you're able to allocate given the goal that you set together, that's quite critical. So we check in quite often, like I said, when I say bi-weekly meetings, those are the least frequent that it could happen, on and off we will have daily costs when something goes wrong, just like all the engineering teams, right? Sure, so I looked at your script and it wasn't that, but you will still be involved with the conversation and just helping foster that, because it's also like you could use that, that you could market as one of your... Yeah, exactly, exactly, yeah. So now it's a collaborative project, but they start leading that whole discussion. Got it, thank you. Okay, good, I think we ran out of time, so if you have any question for me, feel free to catch me afterwards, and thank you so much for attending, I really appreciate it.