 All right, welcome everybody to Flight's Journey, Building and Growing an Open Source Community. Flight is an LFAI in data incubating project. Keetana and I will be presenting to you today. We'll be starting with introductions. What is Flight? A bit about the open source community, and then spend most of the time on the struggles of building an open source community. We will wrap up with what we plan for the future before taking questions. As for introductions, I'm Sandra. I'm a bit unconventional because I come from a different type of engineering background. I studied construction engineering and earned a Masters of Environmental Engineering. But the beginning of my career was in the water treatment industry. When it was time to have a family, I decided to stay home with my children and instead volunteered at their schools, ran their Girl Scout troops and helped our community managing things like early childhood programs and some adult learning programs. I also joined an Interfaith and Outreach Committee for planning events. And all this was about for about 10 years. When it was time to go back to work, I looked at some certificates at the University of Washington starting with a technical writing certificate, I TA'd some content strategy classes, and then earned a UX and visual interface design certificate just last month. I slowly found myself going into the world of conference support and social media marketing for two UX conferences, Convei UX and UX Rider, which in turn brought me to Union AI, the team behind Flight, just in March of this year. I started off as a technical writer and then now I'm in the marketing department as a marketing content manager. And over to Kaiten. Thank you, Sandra. This one? Can you hear me guys? Yeah, hey. So first of all, good morning. My name's Kaiten. And I guess the picture over there sums up my recent few months. It's very hard to get a photo with all four of us. I have a two-month-old at home and a two-year-old and the two-month-old was born in pandemic. And so, yeah, this is the only picture I could find for four of us. But I'm here because Flight is a project that I started at Lyft about five years ago. And I have for the longest period probably been the community manager slash evangelist of some sort on the project. While doing my daily duties at Lyft, and then earlier this year, I left Lyft to start a company that focuses on Flight and related products. So I'll add some color to basically Sandra's story here. I'll just essentially give you a little bit of a background and history of how Flight evolved and so on. And then look at the community aspects and wherever we put color into some various struggles that we had. Just a little bit of background on myself. I'm a software engineer, 15 years. I've been a software engineer more maybe now. I still write code, I love writing code. But the hardest thing that I've done probably besides a lot of personal stuff would be building a community. And that's why I couldn't find a good resource on sharing the troubles of building a community. And that's why we decided to compile this together. From the industry point of view, I've worked on, my recent job was at Lyft before that, worked on cloud infrastructure, mapping, was at Amazon for a long time. And also did high frequency trading, banking. So yeah, went across the gamut. And that's where the need for flight I saw across many years. And that's why we built it. So before we jump into the community aspects, we all need to get acquainted with the product itself. So let's talk a little bit about flight just very quick. Flight is essentially a workflow automation platform that allows users to forget about the machines, write the code, the business logic, and let it run somewhere. So it's in the vein of the new world. It's like a serverless orchestration platform. Within an organization, you operate it like a central service. It comes with the classical distributor systems architecture where you have control plane, data plane, and so on. Also, it is built on top of Kubernetes. So that's the serverless component essentially. And with a heavy focus on reproducibility and replayability and recoverability within the systems. Because these are the pieces that we saw were missing within machine learning landscape, along with understanding of types and parameters and so on. So given the feature set, it's very suitable for machine learning and data processing applications. And we'll go through how we actually evolved even the tagline for the project. It was developed at Lyft about five years ago. And we were fortunate to work with other thought leaders within the space, including Spotify, Free Nones, Tri-Works, and many others. And essentially come up with the project. It was contributed to Linux Foundation earlier this year, maybe I think February. Yeah, and since then, we were able to really focus on the open source journey for the product. I said a lot of things about flight, but where does it really fit in? It's an orchestration platform, so it's orthogonal to really the use cases, but we primarily focus on some use cases. And those use cases rely heavily on data and machine learning processing. So in this diagram, essentially the purple components is where flight would directly be applicable. We have seen people applied to other places, but these are the natural fit for flight. So if you have a data warehouse on the left-hand side, the ETL or the transformation process that gets data into your data warehouse, and once you have data in your warehouse, you want to train, build features, do model monitoring, or do batch inference like fits in beautifully in those places. But before we understand the journey, which I think the most interesting journey has been the last one year in flights life, but let's see the history of flight before the open source. A lot of work went into flight before it was even open sourced. It was born in, I think I want to say, November 2016 over a weekend. It didn't even have a name then. Like as every newborn is born, they're just born out of the need. Instead of having a mom and dad, they were just born because the need that a team essentially had lived wanted to deliver a product. And so it was not built in isolation because we wanted to build a product. It was built because we wanted to actually solve our problems. So I was leading a team that was responsible for one of the most critical metrics at Lyft, and that was the ETA. An ETA essentially is when you open up the app, you see three minutes for a car to come or 20 minutes to reach somewhere. That's extremely critical in two ways. One, it tells the user how far away the car is from them. And based on that, they decide whether to actually go ahead waiting for this car or switch to another app. So it's a very critical metric for conversion, or not metric in this case, actually a measure for conversion. And the second one is actually the ETD, which is the time to destination. And that's very critical because it converts to the upfront fare that we charge or that Lyft charges, and hence, actually directly affects the bottom line and the top line. So very, very critical numbers. They look like simple numbers, but there's a lot that goes behind it. And so I was the person in charge at actually making sure the infrastructure and the product really works for ETA. So when I joined the team, we were doing all kinds of funny things. We were running models on laptops. And we were actually, there was a person who would just orchestrate things. Startups, it was six years ago. So it was okay to do those things, but it was not scaling. It's obvious that it didn't scale. And we had terabytes of data that we wanted to process. And we wanted to do new things. We wanted to actually analyze road traffic and use that to work on things. So at that point, we looked around and because of my background, I was like, there must be something that does simple workflow automation or some sort. And we can build things around it. And we found something. There was one thing around that was called Airflow. We used that, hacked it up. Soon we realized it doesn't really work for these use cases, but we still continued hacking it, hacked it to a point that we could deliver our things. And as successes, you deliver something and other people just start saying, oh, can I use that thing that you built so that I can deliver my own product? And there was another team. And that's when it turned upon us that, hold on, this was not built for being like a platform. And it was actually run without blood, sweat, and tears. And if I had a team of four, trying to do that for another team would just completely dismantle the team. So that time, we wrote a small paper that said, this is the goal of this. We could build something like this in the future that could solve a company's problems. And a company, we were not thinking about open sourcing or anything. We were just thinking about lift. And most people said, this is not, you cannot build this. This is just crazy. And so that's a challenge. And engineers love challenges. And so we got another engineer with me, two of us sat down together. In August of 2017, we actually launched the first version of Flight. Again, no name still then. Or there was some weird name, I forget, model builder platform or some things like that. And another team was able to deliver a model. And they have not been able to do this for five quarters in a row, because of the amount of data they had and the complexity in the model. And that led to word of mouth spread. And then October 2017, more people started using it. And we launched experiments in production. And they were successful. And suddenly the thing that we had built now in two months was adopted by 15 teams in seven months. And we're driving critical business revenue products. So that led us to think, oh, hold on. There's something here. And I think the word reached out to other companies. They talked to us. We had a lot of open conversations with a lot of different folks. And finally, we decided to really rebuild it from an open source point of view. The reason why we decided to go open source is because we realized that the ROI for us as if building it was just not there. We were a small team of five engineers and serving about 500 engineers in the company. On a weekly basis, it would be extremely hard for us to maintain this. And we wanted essentially to work with other like-minded smart people in the world to actually improve the product. So that's when we open sourced it at KubeCon in December 2019. And that begins the journey of our open source. I call it the time of dawn. I didn't find a very good symbol for dawn. So I put a pulp. But Jan 2020, I'm going to take the holiday month of December as kind of a no-op. But Jan is really when we wrote our first blog. And that's open source. And it seems soon now, but it felt long about in a few months. Spotify and Freenome decided to join us and partner with us. And they became top-level partners for flight. And soon USU joined in and some other companies. And at this time pandemic was happening and the world was changing. And for me personally, things were changing. And at Lyft also, my focus on this product was lower because I was leading an entire platform. And I thought there's a lot more to give in this product. And that's when I decided to separate from Lyft. Started a company called Union. And that was in like early this year. And we focused squarely on open source. And we've now can proudly say that we have at least 10 plus organizations constantly collaborating and contributing to the project with lots of contributors. We still think that it's really, really early days in building a product. We know where we're saying that it's a, we've like, you know, hit it out of the park. But we think we've learned a lot along the way. It's the nature of the product is such that it's thrives on integrations. And integrations are amazing to build an open source, not community, but like an open source project that people want to work with. Because it's not just one product then. It's like multiple products that are all helping each other, you know, trying to, and this is needed in open source. We need to stop like building isolated boundaries and come together and essentially build products. Yeah, so that's that slide essentially. But let's, we talked a lot about the product now. Let's talk about the open source community. So when we started about two years ago, we didn't really formalize this and we're slowly formalizing this, but we started with a set of values that we want to build the community with. And just like a company, values are essentially when in the community. And we took a different approach. We decided that our number one value is going to be customer obsessions and customer satisfaction, which is weird, right? It's like in open source, what's a customer? That's a question that people will ask. But yes, the customer is anybody who's trying to use a product. But then who's serving it? So there has to be some set of people who are dedicated to the product, for the product to work. That's one. And then there has to be the community and almost slowly people emerge from different companies and they start working together. And they really care about who feels how about the product. And the more you build it, that's what builds customer obsession. So I think that's the number one thing that we've learned at least that works. We also wanted to build a community that's really open and inclusive. And again, it's because if you look at the product, it's based on Kubernetes. And it's targeted towards data scientists and data engineers. Many times I've seen questions in the Slack channel. We were like, what's a container? And it's completely... For people who are using Kubernetes, it's like, I understand. Kubernetes levels above containers. But for many, many people out there, they've never used containers. And so that's where inclusivity here doesn't really mean person-raised creative. It means anybody who's needing any sort of knowledge that some other folks have, and they don't, you want to bring that together. And so we want to be inclusive to anybody who comes into the community and be open in sharing all our knowledge. The other thing is that we... When we're building the product, because we are having businesses really critically dependent on the product, we care about reliability more than features. We, of course, we love to build features. We are engineers. We love to build new features in there. And the community loves to add features. They always request features. But the priority, the way we prioritize things in the community, we always put reliability a little up. And we're like, hey, this feature might affect the reliability so we push it down. And another thing, and Union.ai, this is the company that we started. We started with the goal that we are going to build... We are not going to take things away from this open source project. We are going to add whatever we can to the open source project. Not really build open core, but really build a good open source project. And then offer meaningful reasons why people could migrate to such a thing. And those could be just because they don't have enough infrastructure, folks. And another thing that we realized when we were building this, because of the set of people who were trying it out, they belong to different cloud companies, the cloud is becoming a slow lock-in and open source is a way out of it. And so we were like, we want to make sure that cross-cloud support is always at the top level. So these were the values that we started with. And for this preparation of this talk, what I did is I reached out to the community and I said, can you share some of your comments or concerns or feedback? And I said, of course, if you're good, then I would put it on the slide. And I was humbled and it's overwhelming how people came up with... And as this is for a conference, most people actually came up with positive things. So I have a bunch of feedback over here. I'm not going to read through all of them, but these are from various different companies who are part of the community and I couldn't actually fit everybody's feedback. That's how overwhelming it was and that makes me feel proud of being part of this community. But I'll quickly go through the themes of the feedback. Why... And the overwhelmingly positive feedback is because people really care about reliability. They like when open source projects don't break them. And this happens more often than not, where a new release of the project, boom, broke all of your existing things. And I'm like, okay, what do I do with my existing stuff that's running in production? So we try very, very hard not to break people. And I think we see that in the feedback. That doesn't mean we haven't broken. It's software. We will sometimes figure out regressions, but we are very quick to jump and fix on it. The other thing is this is open source. People love... And we're in the modern 2021 world. Slack is everywhere. You just want quick responses to things. So people love quick responses to questions that are blocking them. And so we try to answer whenever possible. And I think overall it rubs on the community and the entire community jumps in and helps and answers things. The other thing is just help on when new people come in and how do you get them onboarded. And documentation is extremely important, I think, but documentation is a continuum. It takes a long time to really build. Especially for a hard project. For example, you need to wait to deploy to GCP, to AWS, to Azure. It's kind of impossible to get that all right. So that's where community members come in and start helping. And another thing that I've learned is community is a cycle. People join a community when there are more people in the community. So how do you really... There's chicken and egg problem. So some of these themes that we see over there are people and they'll be like, oh, I joined the community because the community was big. Another thing is absolutely open. I think people will come up with great ideas and crazy ideas and you should be open and take the feedback. And I think we as a community love critical feedback. So critical feedback, actually nobody's given that weirdly here because they knew it was for a conference. But critical feedback actually has helped the product a lot more. And of course, our docs were horrible and we'll see Sandra will go over some of the learnings that we had with our docs and people are now talking about docs, which actually tells me that we are going in a positive direction. And then, yeah, and roadmap because roadmap is the reflection of what people are requesting and what's actually happening. And so they really care about changes in the roadmap and evolution. With this, I will hand over to Sandra to essentially talk about the struggles of us building a community. Thank you, Kaiten. All right. So with the majority of the past couple of years being remote, let's start with our social media journey. So as Kaiten has had mentioned, the Slack community was slowly building in September 2019 while Flight was still at Lyft. It was released in November 2019. So Flight, its GitHub repose, Twitter presence, as well as a YouTube channel. And Flight was announced at the North America 2019 QCon. A few months later in May, we started a Google groups group, I guess. And our first, as we call it, Flight OSS sync up was held over Zoom in June of 2020. Until now, these sync ups are happening every other week on Tuesday morning, specific time. They typically include 10 to 20 members of the community plus the rest of the team behind Flight. So fast forward to January 2021. We started to think, how do we increase our presence? How do we grow? Let's look at some stats. So we started with Google Analytics. And then in the first, in the second quarter of 2021, Flight joined LFAI in data as an incubation project. I want to highlight that second quarter, which is in purple here. I'll keep referring to that quarter as the presentation goes on. So in about, we decided to do something with our numbers. Say, how do we get better? How do we improve what we're seeing here? So we started a discussion group on LinkedIn. We published a flight blog. We started to form a bit of a community on GitHub discussions to supplement our Slack community. We also started to improve our YouTube SEO. And how we did that is previously all of our sync-ups had been uploaded to YouTube as a video title, the Flight Sync-Up and just the date there. What we needed to do was to put the topic and the speaker's name on the title. So when you search for a topic, you can find those videos starting to come up. Also, if we had a few topics being discussed in the one meeting, we started to break those into separate YouTube videos to have more specialized searching. And we also started to documentation revamp. So all that was happening in that second quarter of this year. To date, we have about 540 members on Slack. We have 190 followers on Twitter and about 150 Google members. Sorry, I think that's my mic every time I move. Oh, it's my necklace. Okay. So to look at some improvements, we looked at some quantitative and qualitative metrics. Some of the numbers we could measure included the number of followers on Slack and Twitter, some detailed Google Analytics, GitHub Stars was one of them, and user retention. Some of other non-measurable metrics included contributor feedback, more Allen Slack, contributor and customer testimonials, and just general community engagement. But before we could go ahead with anything, we needed to do something about our getting started, which is what Katie will talk to us about. Yeah. We're going to do the stack teaming sometimes in between. So I guess getting started here refers to the way you start with the software project. And it's critical. I think it's the make or break for an open-source project. And for amazingly successful projects, usually you'll invariably find that it's really easy. And sometimes it's not even related to the depth and the, I don't want to say the quality of the project, but the number of features, I don't think that really matters if it's easy, if it solves one specific problem, it really helps. And our getting started was horrible, probably a year ago. We would tell, this is the first thing, when a user comes to the docs website, they'll say, all right, to get started with flight, first go get a Kubernetes cluster. And then if you have a Kubernetes cluster, now let's install Postgres or get Postgres somewhere. Oh, and then set up Ingress, and now learn about containers, and then finally go to Python, and it doesn't work. Then earlier this year, maybe March or sometime, we kind of inverted this model, and we're like, what if we make the Python library, which is more accessible to the set of users that we really care about, make that work almost end-to-end and well within what they want to achieve. And so the first thing was pip install flight gate, and you can get started with it and it runs. Now that you have that, the next thing you do is, does it work for you? You ask that question. If it does work for you, let's scale. But even scaling has to be really, really fast. So that means, what does that mean? You need to be able to try it out in this real world. We did the pip install flight gate, and people still were like, no, no, I want to install a Kubernetes server somewhere. And they're like, hold on, I want to install a Kubernetes server. That matters because they're like cloud providers. They're on-prem. It's just everything differs. And so we actually decided to come up with one Docker container that contains an entire flight installation, including Kubernetes and the entire stuff, and so that you can just say Docker run one thing and it runs. We found that even that was not great. So we actually ended up writing a CLI that allows you to start that, we call it the sandbox environment, very quickly, wherever you want, locally or somewhere, to try out flight. And that we think has really helped users understand how to get started with it and try out flight, because otherwise we would lose people even like, install ingress, all right, but I am leaving. So that's why we think getting started really matters. Now that we know getting started matters, we have other things that we did, and that's Sandra will work with. Okay, so with our documentation, something needed to be done. Initially, our docs were a collection of pages that had been written by anybody and everybody who had the time to sit down and write something. The style was inconsistent. There were a lot of errors, empty pages, broken links, and not too many illustrations or diagrams to brighten up the pages. Troubleshooting was basically a how-to page with links to several of the other pages. So in order to make this look better, as Kate just mentioned, we started with the getting started page. Similarly, we started sections like the user guide, tutorial, concepts, deployment, and made sure our community page was clear and had direct links to where everybody needed to go to join our community. We also very recently started to embed videos from our syncups, take little excerpts of them, our little demos, and embed those in the documentation. And very soon we'll be incorporating a style guide across the whole set of the documentation. So that's in the works. Basically, to be successful, we think that every feature needs to have documentation for without documentation. The feature just does not exist. It has been said that good documentation is very, very good, but when it is bad, it is better than nothing. Also incorrect documentation is much worse than no documentation at all, and we don't want to be there. So we will start looking at metrics and we'll take a bit of a deeper dive into those. Let's start with our blogs. So the first blog for Flight was published in March of this year. It was basically an introduction to Flight. We later had three blogs released in April, a couple in May, and then one over each of the summer months, and then two this month. So the blogs are basically announced over Twitter, Slack, our LinkedIn discussion group, and the Google groups in addition to most recently our homepage. So if we check our Twitter activity, so taking the months of May and September as examples, we were able to notice that on the exact same dates where the blogs were published, we had a jump in the activity. So May 13th, May 25th, actually May 13th might be that one, May 25th, and then September 2nd and September 9th. So we were able to see a direct correlation between the dates when the blogs were released and Twitter activity, bearing in mind that we announced almost everything on Twitter. So things like our Syncop, any announcement, our releases, everything is always on Twitter in addition to the blogs. So that seemed to be working for us. Moving on to Google Analytics, we're going to refer back to that second quarter that we mentioned in the social media journey. So right about March, April, and May is when we started the big documentation revamp, getting started and everything. So we can clearly see the more we worked on our documentation, the more peaks we have in just general acquisition. And also traffic acquisition seems to reflect the same trend. So the more we worked on the docs, the more peaks we seem to see. Over the summer, when things slowed down a little bit, so did the peaks. And judging by that final section, looks like we need to do a little bit, we have a little bit more work to do. So we have that in mind. The more we shop in our docs, the better we publish and the better we tell the world about what we are doing, the more activity we can see. That's kind of where we're at at this point. Also engagement, we were able to see that it was directly related to our documentation revamp. So when we started in April, there's that little jump right there when our getting started was updated. The other documentation followed and then our YouTube SEO was improved around this time in June. And then when we finally had most of our documentation in shape, we see that peak up there. So again, when we slacked a little bit over the summer, we could see a little bit of a drop and then when we picked up again September, those peaks over there seemed to reflect that. So it's good to be able to see that when we do work on documentation, we do see direct correlation. GitHub Stars is another one, another metric that we measure. It's a little bit tricky because it's not a measure of how many people are actually on your repo. It's more how much they like the project or how much they think the project is interesting. Some people actually start a repo because they want to bookmark it for later reference. So it doesn't really show, there's no way to know why people are giving stars. There's no way to measure that. So even though there are some limitations, we're still able to see that large jump when we first released around the beginning of 2020 and also another jump up here when we started to improve our documentation around that second quarter right there. It might be more useful when you have a GitHub repo to check the number of forks, issues, commits and PRs to judge or to be able to measure how active your repo is. To date, we have 25 repos on-flight. So yeah, go ahead and check us out sometime. At this point, we're able to comfortably say that Slack remains our number one communication platform. We had tried other channels to build the community and reach out to people. This course did not have traction at all, unfortunately. And then when we started the LinkedIn discussion group, the trouble with the discussion group is that you can't share posts externally. They just stay within that group. It's not the same as having a LinkedIn group for a company that way you can share. So that hasn't been extremely helpful, although we still continue to post to that group. We tried to establish a community on GitHub discussions, but we noticed that the discussions are always referring back to Slack. So they start on Slack, they move to GitHub, they go back to Slack. We did response, we tell them, go back to Slack, somebody will respond almost immediately. So that's still there, but it's not terribly useful. And with Google groups, we do send out all our communication there. We know we have some members, they're steadily increasing even slowly. But there's no way to get stats for that. There's no way to measure how useful it is. You send an email out there, but you don't know how many people are reading that email. You don't know if they find it useful or just send it to trash right away. So we are continuing to do that, but it's difficult to measure how effective it is. So we're going to stay on Slack. We're going to focus on that as our main communication platform. Over the past two years, since it has started, we have been averaging about 120 real-time messages every day. So it's extremely active. Responses are almost instantaneous. We have about 550 members at this point, over 20 channels. The only disadvantage for this Slack that we have right now is that it is not free if you want to keep record of more than 10,000 messages. So we know a lot of useful discussions will be lost, unfortunately, but that's something that we have to either live with or figure out what we want to do with. But for now, it seems to be working. We're getting a lot of traction on Slack. As for outreach, Twitter seems to be our number one platform at this point. So everything we do will go on Twitter and we are about close to 200 followers at this point. Now, with regards to our contributors, we've been able to see that at this point, our contributors span 112 countries and about 1,500 cities, which is really humbling, as Keaton had said, to see how far an open-source project can reach all these people. Even if it's one or two people in a city, it's still outreach, it's still widespread. Again, activity with the users where it was peaking during that quarter, April to June of this year fell a little bit in the beginning of summer and it's starting to pick up again. So that's a good sign. And this is again consistent with documentation updates and mindful social media marketing. Then we decided to look at Lynx Foundation stats, LFX. And we noticed that our contributor strength has increased by almost 400% in these last two years, which is great. But this graph is a bit more interesting to look at, our contributor growth and retention. So when Flight was first announced, we see that our active users are steadily increasing, which is wonderful. What hit here was COVID. So February 2020 everybody stayed home or probably around March. So that's when activity started to drop a little and our inactive users increased a lot. By the end of 2020, everybody was kind of figuring out how they worked at home, how things are settling in. Activity started to pick up again and our active users were slowly increasing again. February 2021, March 2021, that's our quarter there. That steep increase is right there and our inactive users are slowly decreasing. So we did cross that point again where our active users are much more than inactive users. So it looks like we're heading in the right direction. We should keep going. I'll hand over to Kayton for contributor confidence and a couple more slides. Just one clarification. I think the previous one was contributors, essentially people who are contributing in terms of code or some sort of thought process. And the one before that was users who are some definition of users who are able to come and look at docs and so on. So for the contributor confidence, contributors, it's amazing to have contributors in the project, it's humbling, you start a software project and you're like, I'm writing code, but I want to open source it. And the reason why you open source it is because you want to get more people to contribute to it. So contributors are extremely important for the success of a project and contributors only can come through if they're confident in contributing. And confidence is a very hard metric to measure, but we think we have some qualitative measures. We think if you don't have too much documentation and not enough insights into your project, there are still some contributors who come in and contribute, which is just fantastic because they go and read the code. But there are many others, it's just inaccessible to them. They just don't know where to contribute because I think the vast majority of the engineering population in the world is still on close source. They're not as open to contributing to open source. I think it's converting, but still it remains a reality. Moreover, they will not contribute if they check in something and it breaks something. Once that happens, it kind of puts you into a shell and you lose the contributors. So you have to make sure that confidence goes higher. And for that to happen, there needs to be simpler ways of making sure that the quality of the code that's being checked in is high. Now, that could be based on code reviews, but code reviews are extremely hard. Like for a project that has 25 repos and has like lots of code in different languages, it's extremely hard to get a full coverage with code reviews. It really has to be programmatic. And one of the things, the other things that we realize is that there are many contributors who come in and who try to solve their one problem because they are like, hey, I was using this and I found that this one thing was missing, so I'm going to fix that. And that gets checked in. And this is extremely true with integrations. They integrate. And then they go away because they got what they want. They're using it and it's working for them. But who is responsible for maintaining that it continues to work? And that's the community and the core team and so on. So we think having high coverage and constant tests is the only way to do this. And especially for products that are trying to integrate with a lot of things, it's actually much harder. If I was to choose something, I would choose not to integrate with too many things because it's much easier to maintain quality. When you start integrating, you have to be dependent on other things and their APIs and their interfaces and their breaking patterns and so on. And hence it is essential that somebody needs to do the constant tests for all of this. And if you're running constant tests, that's not cheap. It's very expensive. You have to run them on Kubernetes clusters or in cloud providers, in on-prem or GPUs, especially if it's a machine learning project and so on. And that becomes extremely expensive. But we are trying our best as a community to constantly keep up the contributor confidence. And some of our decisions, design decisions help in that. We are spec-based and constantly based on that. Everything is first specified and then implemented so that helps us in maintaining some of the confidence. I guess one of the last things we realized is positioning. And this is a very soft topic which people don't really realize. And we definitely did not. When we open sourced, we didn't have a tagline for the project and we didn't know if it really mattered. And I can honestly say it does matter, right? So when we first open sourced, we were like, okay, what should we call this thing? We were like, okay, it runs on cloud and Kubernetes. So let's call it cloud native. It's used for data and machine learning. So let's call it data and machine learning platform. Absolutely the wrong thing for the system. It's not a machine learning platform. It's not a data processing platform because if it is, then it's like it's everything. It's too big of a thing. And this misleads people. When they come in, they're like, oh, I expect it to do XYZ and it does something else potentially. So, and we realized this quickly because we got wrong questions. And then we're like, okay, how do we correct this? And again, not enough of a thought process. We were like, okay, let's kind of course correct. So we said, accelerate your data and ML pipelines to production. Part of it is the truth, right? Like it's a pipeline and you want to do in production and data and ML. But it's extremely vague. It's not clear. It's not obvious. And so then we did another positioning exercise and we were like, okay, what? And we talked to a bunch of folks. We talked to the community. We tried to understand. And then we said, okay, this is why people are coming here and this is what we should talk about. So we said it's a workflow. There is a workflow engine component to it. It's a workflow automation platform. And what are people using it for? Data and machine learning processes. And the reason why they come to it is because of scale. So we make it like that. And we also realize they only come to it because it's been used in production for a long time while many of the competitors are not used in production. So we're like, okay, we'll add all of this. But then we again got some folks who are like, oh, I want to run this. I don't have Kubernetes. How do I do it? Oh, okay. So we had to, you know, further course correct. And we were like, okay, we should put Kubernetes in there. So this is the final thing that we came up with. And some of the others, the competitors, like they say we do X, Y, Z, you know, other stuff. It's kind of confusing instead of showing that it's like, you know, the breadth of the product. As engineers, we want to show that it can do 100 things. But instead, and that becomes very confusing for the users. They really care about the two things and they like when something does those two things well. So that's how we decided to position. And I think it's fair for the users. It is the right way to reach the right set of people. And it helps in, in actually reducing the wrong questions and assumptions. All right. So that was the quick history and story of us building the community. But I will hand it over to Sandra for, you know, talking about our future plans. Thank you, Payton. We have just a couple of minutes left. So we'll go through this quite quickly. Our next steps are broken into community outreach and what we can do with our documentation, like the technical side of things. With our community, we're going to try to encourage our users to write blogs instead of having us write them every time. We are looking at releasing a newsletter next month, focusing on Slack and widening our LinkedIn outreach. We are also thinking of joining a group called Talk Openly Develop Openly and collaborate with both other open source projects and many integrations. As for our product and user experience, we will continue to better documentation, clarify our roadmap, streamline user experience by showing them better ways to get started, better UI, and also remind them of any software upgrades that we have and any specific versions of software they should be using for streamlined experience. In the long term, we have a Flight 1.0 coming out and only two integrations to go to graduate as a top level project in LFAI and data. All that in addition to our performance improvements. There will be three other sessions that Flight will be giving at OSPACON. There's one today, one Tuesday, and one on Wednesday. Neils is with us actually today. He'll be presenting this evening. And we are participating in Hacktoberfest next month. Join us on Slack. We have a channel there for Hacktober and a blog group coming out soon. So thank you for joining us, everybody, and we are open to your questions. Any questions? I think we can help answer. And of course we'll stay around for, you know, people who want to do one-on-one questions. Yeah, so Amrita, the question here is if I may repeat it, is for the contributor confidence if we have tried on an onboarding process of Sunstar as well as mentorship programs. So I'll answer them in two parts. For onboarding, yes, we do have a contributor guide. We, for every repo, we have tried to improve how you can contribute to each one of them. We centralize all our issues onto one repository so that people are ready to go and look for other things that are happening. And we, the documentation in general, usually the code is documented. Our code is written in Golang for most of it. And then we have our user libraries written in Python and Java and Scala. So we do get contributors from different language sources. But to answer mentorship, like we are, like me and a few other folks do help folks. Absolutely. We do, like, Zoom, Google Meets. Any time they win questions. But we don't have a formalized mentorship program and we would love to. I guess we did not have that big a community till recently. Again, not big right now, but like we actually can have some mentorship and people have contributed to different parts now. And so there would be enough depth and breadth in people that they can help mentoring that. But that's a fantastic suggestion. I think we would love to definitely put that in there. In our contributor doc, essentially to say, like, hey, if you want to mentor and you want to contribute to something, click this button. That's a fantastic suggestion. Thank you. Community Development Program and Source Project. When you were starting, like, opening it to the general open source world and developing your initial open source community, what resources did you have available to work with there? So I was at Lyft. Lyft did not really have an open source program office of any sort, but it had Matt Klein, who I guess many people know him. He is the person behind on why. And Lyft has been a big contributor to open source in the recent years. So the only thing that we learned is essentially through talking to other folks who were either contributing or opening up their things and we learned a few things. I didn't know, but maybe I didn't look enough, but I didn't find a talk that were just like, there's still such these things, these learnings. That's one of the reasons why we put this doc together, essentially, so that next time when you're doing an open source project, hopefully you don't do this after a year and a half. You do it on day one, because it does really help the project. And on the side note, I'm going to say that we at Union.ai, which is the company behind it, we are looking for open source community managers for the flight projects. If you know anybody, we would love to talk to you. Any other questions? Yes? Yeah, you just said, my name is Union.ai, but you said on day one, I'm sorry, I came in a little bit late, but really to find the day one, how kind of put together from a technical point of view does the part have to be before it's, how early and half-baked can you begin engaging and have that engagement back. I'm very curious about things that are more in the idea phase. Coming soon, want to be a part of this. How do you begin to create a shared community while it's still not ready? Fantastic question. I think your positioning really matters over there. Number one, right? You need to be absolutely honest of what it is and what it is trying to be at the moment. Not about what it's going to be two years in down the line, right? Because I've seen some projects where they talk about a lot of things and when you go into the project, there's not much. And one way of doing it, for sure. The reason why folks chose to use us in some cases is because it was production ready. It worked in production, right? But on day one, it was production ready still, but people didn't really want to use it because they couldn't. So if your product is production ready but it doesn't really, it's not really accessible, features don't matter, right? The completeness doesn't matter because it's like, you know, if you don't have documentation, it really doesn't exist. So that's one. Second, don't lie, just be honest. I think people understand, right? The good contributors will come in and they look through it and they're like, I know what this is happening. Or, you know, this is awesome. I really want to go behind this cause and I want to help this. And there's no momentum like that momentum. So it's very hard to get that. And then, of course, marketing really, really helps. Pandemic and the last year did not really help us and then lift situation and the world situation. Like we just, it was one person driving an open source project. It's kind of impossible. So if you have enough people, I think that really helps in the beginning of the project. I hope that those are roundup answers but hopefully that answered your question in a weird way or no. Yeah, I've always thought about like that. That very first hurdle to get something production ready and I think it's different from the product. Yes. And to be able to incubate it in a way within Lyft is a gift. We were lucky. We were absolutely lucky. But what if you don't have that? What if you want to get a bunch of like-minded engineers who want to solve the same problem but really it's from scratch. It's a long way from production ready. Yeah, and I think that's a really hard problem but I think be honest in that. Just come up and say like, we think these are the set of problems and communicate openly. Now, we do see that if you communicate to openly about certain things that you have not done, we had a coming soon sections in our document that people hate. We actually got a lot of negative feedback for that. So people do not like coming soon sections in their docs. And then the other thing that we realize is that sometimes it becomes over marketing. Are we out of time? How do you manage priorities? Priorities across the product or... That's why the values matter. The priorities in an open source project is very interesting. If somebody comes up and says, this is extremely important to me and I'm putting three resources on it. Spotify basically said that we wanted to build like the Java SDK, Java Scala SDK because we are going to use that. And they built it. Now, for the community, there's open prioritization over here. You just go in and like, yeah, sure. We'll support you in the sense of mentorship, but we can't really write code. But then other cases, they don't really have those many engineers. So they'll be like, hey, we need this. And then it becomes where the values really help us. Well, like, is it really going to improve the reliability or going to affect? If it's going to improve the reliability, then we actually trump that over some of the other features because you can create broad features, like unlimited number of broad features. But what we've also seen is, flight is such a broad product that you can have hundreds of features. 20% get used. They really matter. So let's just focus on this 20% and make sure that the 20% stay low. Are you... No, no. The TSC, the... So I'm also part of the TSC. You have a TSC? Yes. We're building it. It's low. No, not union.ti. It has no calls. The only thing that union.ti makes calls is like, can we offer one more person to help with? How far knows your TSC? We just about getting started. We have folks from Spotify, FreeNome, a couple other companies that cannot name at the moment that we are creating. But we are not a graduated project, so it's not completely formalized yet. But that's part of the graduation. So we are aiming at the end of this year. We have a formalized TSC with the chair and board and so on. Somehow we already have that. That is amazing. Sometimes that might slow down certain things, potentially. I think that's why getting like-minded people in the TSC really, really, really helps a lot. And I don't know what community... It's an insurance. Locked in place. Any other questions? Fantastic. I think... Thank you for showing up during pandemic and hopefully we could share certain things with you guys. Thank you.