 Welcome everyone. In this session we'll talk about building a community growth flywheel. My name is Jasmine. I run the open source community at Eluxio as well as developer relations. So this is the outline for today's talk. We'll provide a deep dive into the methodology and framework that we used for building the Eluxio open source community and share some of our experience and how to integrate the open source in the company's business model. Of course, share how you can build a flywheel such that you're able to build a system that the community can generate growth on its own while resulting in our eye that benefit all departments in a company as a whole. And of course we'll also share some of our learnings on cross-community collaborate experiences and other examples. Before we dive into there, I want to take a little quick look at to give you some background on what Eluxio open source project is about because not everyone probably know about it. We actually started as a open source project at UC Berkeley's Amplac and back then the name was called the Tachyon project. So after seven years, of course, we changed the name of the project. They were the same group of people. We now have a very large and vibrant open source community with over 1200 contributors still growing and 9,000 members on our community Slack channel. And we're also recognized as one of the top 10 most critical Java based open source project by Google and open SSF. And it was named one of the most valuable repository on GitHub. So as the person who's in charge of the community channel, I would love to welcome all of you to come check us out at eluxio.io slash Slack to see what the community has to offer. Now what is Eluxio? So other than just being an open source project, we're also a company right now. And the product itself is a large distributed system that is a new layer between the compute engine and the storage systems. And this layer provide a complete virtualization across all data sources to serve data applications who do not need to worry about the location of the data. So the solution is also applicable across all environments, whether it's being a cloud on premise, bare metal or containerized. There are two versions of eluxio, as I mentioned, because we do have an open source version that is a community edition free for all. As a company, we do also offer an enterprise edition that help us to generate revenue. And as a product, we have seen thousands of organization currently using eluxio. And we also seen success across different verticals with technology company leading the way. And of course, more regulated markets such as financial services, pharmaceuticals such as shifter security needs, they've also adopted eluxio. As you can see, we have a pretty vibrant community right now and the products also thriving, but it's not always the case. And otherwise, we wouldn't even have this talk. So we were just like everyone else, not very clear at the beginning, and we do not have a dedicated community team until about four or three years ago. And since then, we actually started a dedicated open source team and decided to include open source as a key component of the company's business model, which means we're going to involve some company resources to build the open source project as well as the community and create a dedicated team for that effort. Now, that decision, of course, has as a merit, as you could see, the business model for eluxio is to sell the enterprise edition and then by having a broader community edition version adoption can largely influence our sales and our conversations. Our mission. So people always talk about what do you do as the open source team. I tell people what there are two things we focus on, awareness and adoption. What is awareness? For example, when we go out and give talks like the evangelize and educate about the eluxio technology to the people who know or may not know about eluxio, that is awareness. We can also extend this awareness to the related ecosystem, whether or not to the tech stack that's strictly integrated with chat or not. And adoption that includes land and expand eluxio usage that can also include building champions for the individuals that can help eluxio to expand its influence globally. Alright, so now that we have a give you a little taste of open source program at eluxio, we're going to move on to the meaty part of this talk and share the methodology and framework and building the program. The flywheel model. So when we first started the open source team, we were hoping to find that secret sauce for the community growth. And the first thing was to find out who are those people in the existing community sock channel and what level is their usage and why are they here at first place. So when we mapped it, we found there are relatively new members that are somewhat experienced users. And of course, there are a lot experienced contributors who are actually able to contribute back to the code base. Now once we map that out, we found that the step two would be try to build a system like I said, such that the community can generate growth on its own given the right input. So basically, we're trying to build a flywheel for the community growth. So the concept of flywheel you might have know is based on a, you know, James Collins book is a concept taken from his book to great to put a simply the idea is that your customers are your best sales people. So if you can make them happy, then they go tell their friends and your business grows. So in a community case, we focus on growing that, you know, we want to make those experienced user happy. So that's happy customers so that they can go be the force to generate enough momentum and bring new users to tell their friends. So right now you see in this graph that dine is still dotted because it's not happening yet. So our goal will be to close that loop to be a solid line. Now this will be the new map that what we'll believe. And once we complete that loop that can help us, we realize the way we map this is we realize there may be a missing piece when we're mapping that because if we take a look at the members activity based on the profiles we discovered earlier, ideally there should be four kind or let's say four step step activities and open source community member could do, they could discover or they could try out, they could contribute and they could advocate. So if we map out those four activities and then we map into, we will see there are new members that discover, there are new users that probably try out, there are contributors who can actively put back their effort into the code base and then there are probably fourth category with call them super contributors who are more vocal and they can help to advocate the products. So in the previous graph what we're missing are the super contributors. So now we know that what we're missing in theory by having the super contributors. Now the next step is how do we nurture those so to help to close that loop. To nurture those people I would say believe that that designing a killer developer experience is can help that is pretty critical in this process. So this graph that you see on the slides is taken from the DevRel book. It kind of explains the key elements for having a great developer experience. I don't want to mention that there may be very different kinds of super contributors. I know you will need to design different developer experiences based on their level. All right so now we're looking into how do we design that experience now that we're talking about it. It seems pretty straightforward first your survey and then then you identify the ones that you want to nurture and then you collaborate with those individuals right. Now however let's take a deeper look at the second state for our company because of the nature of our product. So we did a three definitional measure for each target that we want to select and identify. Because we are a to-be feature the to-be feature of our product the ultimate user or buyer are guaranteed to be a company instead of an individual consumer or let's say a school student. So in that way we do pay attention to the company the organization of where this user come from. And of course the second dimension we do take a look at the use case. We want to see whether they are addressing a problem that we want to focus on as a company or it can help us to expand territory or in a worst case scenario are they trying to go to the the opposite direction where our product want to expand right. And then of course the third dimension will be the individual themselves. When it comes to community cross community collaborations or community collaborations it is fairly important that we want to align with each individual their interest and to help them to achieve their goal. So when those are the three steps. And now let's take a look at when we say cross community collaborations right. So one example of having those super contributors right to close to help us to close the loop is to have those cross community key collaborators. They could be your key or your cross community collaboration key players. The example I give here is a collaboration with a presto community that before we even formed the open source team. Back then Facebook and now Metas Presto team played a pretty key role in kicking off this initial collaboration. And together we built something called Raptor X which I will link that to you later. And then as you could see from that collaboration there are a few things that we got from it. One is before we actually started working on that together a lot of those you know presto committers they were not a lot of users. So after that collaboration they kind of leapfropped from not being a non-user to be a super contributor and also being pretty vocal and helping us to activate the elixir technology. And then the second benefit we got that is that we were actually able to tap into a pretty top tier community access by having that collaboration and we learned quite a bit from their community and then the presto committers themselves. And of course another benefit we got is we did make a new friends and those are all technically very strong and then passionate about open source. And then on top of that you know those friends actually helped us to create a pretty good talent pool and then we were able to recruit a few friends from that community as well. And last but not least by completing that process it helped us to establish this new process playbook that is now being applied in our new collaborations with Uber and TikTok. All right so this is when I say this is how it kind of started at Raptor X as I mentioned if you guys are interested if you're free to go check it out. Like I said the presto team back then they adopted desegregated architecture in a short timeline so they reached out to the Luxio team and then we decided to help them out to found that it was a technical good match so that's when the collaboration started. Now that being said where are we now? Like I said we're applying that to both our current collaborations Uber and TikTok. We also see some new results on our ongoing collaborations Uber. So if you're interested go ahead check out this new block that we just published on engineering Uber engineering block on speeding up presto at Uber with a local cash as well. So this is also a second media part of this conversation of this today's presentation I want to focus on other than just dive into what we did. There are a lot of challenges and solutions when they come across community collaboration when you're trying to nurture a super contributor from another community or another organizations. So let's talk about sort of the non-technical challenges first. First of all you have to make it a priority when it comes to cross community or cross organization collaboration unless it is a priority and endorsed by the larger community or larger organizations we're never going to make any progress. So the one way that we found and how we can make it a priority is really make sure there is a strong technology fit. So you have to answer technology from a technical perspective. In our case when we're matched with Meta when we match with Uber is because we see how exactly those two texts that could integrate together. Now that you've made it a priority immediately you will face the second challenge which is very tight timeline. We all know nothing is a priority unless they have a super tight timeline and especially for first time collaborating. So based on our experience the best way is you know to help to achieve that timeline is by breaking it down to set very achievable and aggressive timeline and break it into small milestones. Here I give you a few examples when it comes to technical cross community collaborations of what kind of timeline you could set. For example you can set a timeline for when a design is completed and when a workload and analysis should be done when a shadow test or when a cross test should be done and when you know you have a deadline you have a goal for when you want this things to be in production and of course if you want to wrap the code up then you should also have a code completing time. In our case those collaborations are still ongoing so the code is always ongoing and in those processes you always need to have very well defined tasks and an owner on each team so that we can build confidence in each other. All right oh sorry runs okay so now that you set the timeline the next problem that you might be facing is having complex feature implementation on both teams. So a relatively comprehensive set of feature will be required when it comes to a larger project like this and then also you know so the way you resolve that is by having incremental approach and then by having constant alignment during incremental release that break the future down sets into many steps this also helps with testing as well and then we also do deliver and test a feature step by step and then you go and define and refine the specific problems during each iteration and release. All right the next problem the challenge that we sort of put in our process book is the release cycle and buck isolation if anyone work across team even if it's within the same organization you might realize the release cycle could be a little bit often issue organization and also on buck isolation so the way we face that is because we cannot afford to be each other's blocker in this case the longer your weight the more variables you introduce so we've decided to create a lightweight release process and to make sure that entire release cycle can be completed within one week and then this can also be applied for a buck exhalation because not all logs can be shared we cannot solely rely on that so you know buck exhalation between different organizations as we built this error counters that error could get to the metrics for us to check out on each other. All right so what would be the fifth challenge so which of cross project quality control we know in each individual organization you probably have your way of checking the quote quality control but when it comes to cross organizations really how do you validate that how do you show that the code is in high quality the both parties have to provide required tests in this case and across validated from both sides we do cross environment workload test we you know in the Facebook space in Meta's case they do skill test and running test in duplicated real production workload in their environment and we run the end you know extra benchmark test in cloud in our environment. All right another possible challenge of the communication channel this is us sharing with you based on our experience what would be the best best way by far so far as the google doc why people sometimes say let's get on a slack channel you can ping each other easily you can write everything down an email in a more formal way you can get on a phone call we do get on phone calls but at the end of the day it looks like a lot of things just like when you write down in doc in documentation is always important so we actually use google doc to make a lot of documentation progress and agreements as and we refer back to that doc as a running doc when we you know have to write more formal emails and then also arrange what's on the to-do list so both sides people can have access to it we can see where the daily developments goes I know where the you know but emails is more I would say for critical decisions and a more important agreement and that's when we send it to lico and by email. All right last but not least turns it happens in every organization so when when the project is on the right track because you know we so we need to build a preventative measure to face possible a personnel change it happens in every organization whether you know it's coming or not so the way that we try to prevent it is we really pay attention to the documented knowledge dump from the beginning so you want to write down not just the project of details but the vision the design implementation pretty much everything that you can think of at the same time you run project together with your pre-owner and new owner when there is every when there's a turn of ownership or exchange of ownership and then just help to settle the ownership change so here I do want to mention that in open source community is usually fairly friendly so you do get quite a bit of heads up when there is a possible turn on where there is a possible hands off and then the one good thing about contributing to open source project is that people are usually not bounded exactly because it's not closed source as you know even if they change team or they change company they can still you know dedicate some time to working on the open source side or hand down some knowledge so that's the nicer part all right there is always a bonus challenge partner engineering burn during pandemic because most of the things that we worked on like I said whether it's a collaboration with meta or collaborations uber and tiktok right now we're glad the pandemic is almost over but most of the work was done during pandemic so we did realize that relationship building is quite vital because when people cannot see each other face to face you need to build that trust you know with each other especially cross organizations you need to understand who your direct partner is in person as friends at best and then to to understand what their goal is what the project goal and what the company goals and to have that constant alignment we do have our regular meetings like I said pretty much if not weekly basis we do have a pretty formal meetings and almost on a daily basis of anything that we need to just pick up the call and chat with each other we'll do that and then you want to get the confirm the buy-in from the management as well all right so that's when you do cross community collaborations and the challenge now we'll shift to another topic on you know in terms of that flywheel so we did mention that when you have users you have contributors you have super contributors that generate to have new users one of the things that you can do as an organization who runs the open source project is by organized special interest groups and hand to those groups the leadership to your super contributors to your advocate that are not necessarily working for your organization so as this is something that we observe as when Olexio was growing as a community when we saw that user are using us in breadth and depth we've seen community organically organized and make faster progress in working together so we took it upon ourselves to to form those special interest group and to push forward the progress we helped to set up making regularly to discuss issues features bucks optimization road maps and whatnot for example you know we some of our core maintainers are working closely with engineers from back then Microsoft Ali Baba and NG University to investigate in running deep learning workloads on Olexio and from that process as that by setting up this special interest group on this particular project the RI we got from that we were able to expand the ecosystem and we give birth to a new open source project actually back then and we also pioneered a new machine learning and deep learning scenario for Olexio open source and also we established a new process playbook for how to run those special interest groups and now following that similar process we're leading a new effort for the special interest group running a presto on Olexio like I just mentioned and we have kicked out that community sync on that direction as well with engineers from Tencent and Robin Herch drowning and co-lead that effort so the key important part for the special interest groups is we as a community owner we can help to operate and by setting up the operations but hand the right to those people who are actually hands on working on those to be your advocate. All right another example of how you could you know turn that freewheel is really leverage your PMC members what are PMC members those are if you're familiar with a lot of other Apache project the PMC are project management committee members so by definitions those are your technical expert on this open source project and they're very strong with their technical ability and they have a louder voice in the community already so people do look up to them by leveraging your PMC members in your community they can help you help others to adopt your product and refine and scale if their current organization is using them so and then they can also provide a pretty critical product feedback at a scale that is probably only possible at a very few leading companies in the industry and as individual they also output a very strong engineering including leading specific features in a certain release and then we can also help them to hold some open joint open source events to give them a voice and it produce lots of high quality content and share it with all the other users so do try leverage your PMC members. All right another example of how you can turn that flywheel as ideally your super contributors one day can be your economic buyer that will be your sales teams stream so this does happen it could take for a while but it does happen in our experience and that a way that you can make it happen as community owner is first you need to make sure you have the right developer education in place so that plays an important role in this part they have to understand that what's the difference between your community addition and enterprise addition and what level of support your enterprise addition will be able to provide them what will they be what extra will they be gaining by converting to an enterprise addition customer so that also means we need to have a very well defined difference between those two product and of course the ROI you can get from that is the immediate revenue gain for your company as well as having an internal champion from the community side now turning to your internal technical guide as an enterprise customer. All right now we've been talking about ROI but don't just stop there so we are well aware by including the open source in the company's business model that you will be measured by ROI at the end of the day we're not spending money just to try to reach developers because we love spending our employers money or spending time to help them because we have so much time on our hand we are doing it because we do expect some positive ROI on what we spend that means over that time you need to measure whether your effort can result in new users new revenues or new territory so by having those you know super contributors by turning that flywheel so you want to eventually define those advocate those champions to be your subject expert and technical lead they can also turn into a nobbing buyer and it can be so much more so I'm going to go through a few examples with what kind of different kind of super contributors and ROI from them oh actually we just went through all right so now that we have that wheel let's revisit that we have users who try out we have contributors contribute and we have super contributors or advocates who helps to be loud voice in your community who can help in turn bring your new members that discover your new product your open source project it is important that we go and fine tune your flywheel and constantly adjust it you don't just stop at one thing because your resource is usually limited and the community and your internal open source team are both evolving over time and your output so therefore your output metric may be changing and the way you do it and you need to tune your input action to match your the output metrics that you desire by adjusting the effort and resource allocation so recall that initially we did include when we include open source into the company's business model the goal is to benefit a company as a whole so to adjust the team makeup as well as projects so in this way you can think of for example from the marketing team what you could do is you provide them the content by providing community events and adding kind of strategy for the product team you should be able to provide them product feedback and adding community product manager to do that if you need to to have a dedicated person and for the sales team of course you'll be providing a more broader base of possible sales and then also economic buyer and insights and influence from having that broader base and of course there should always be very close collaboration and joint development with your developer team with your engineering team so designing an internal system to track your contributions is also quite important so that you can see what's working and what's not working and then another way is you've got to adapt and adopt a localized strategy if you do have geo dislocated geo distributed teams in our case and not only we have a team in the US and Amy up we also do have a local team in China and then because of the difference in culture our China team do experiment with a different gamification system to incentivize their Chinese speaking community users and to try that out all right so that's all for today on how you can turn that flywheel for your community thank you very much for tuning in again I would love to invite all of you to check out our website to join our Slack channel and follow us on social media and should you have any questions feel free to email me i'm jasmine at alexio.com thank you again