from San Francisco, California. It's theCUBE, covering the IBM Chief Data Officer Summit. Brought to you by IBM. Welcome back to Fisherman's Wharf in San Francisco, everybody, my name is Dave Vellante, and you're watching theCUBE, the leader in live tech coverage. We go out to events, we extract the signal from the noise, we're here at the IBM CDO event. This is the 10th anniversary of this event. Caitlin Halford is here, she's the director of AI Accelerator and Client Success at IBM. Caitlin, great to see you again. Wow, 10 years, amazing. Thank you, thank you. And Carlo Appaglaci is here, who is the program director for data and AI at IBM. Good to see you again, my friend. Thanks for coming on, two CUBE alums. Wow, this is 10 years. And I think theCUBE has covered probably eight of these now. Kind of we bounced between San Francisco and Boston, two great places for CDOs, good places to have intimate events, but, and you're taking it global, I understand. Congratulations, congratulations on a promotion. Thank you. It's all going. Thank you so much. So we, as you know, well know, we started our Chief Data Officer Summit in San Francisco here in San Francisco in 2014. So this is our 10th one, we do two a year. We found we really have a unique cohort of clients that join us, about 140 in San Francisco in the spring, 140 in Boston in the fall, and we're here celebrating the 10th summit. So Carlo, talk about your role and then let's get into how you guys work together, how you hand the baton off, and then we'll get to the client piece. Yeah, so I lead the data center lead team, which is a group within our product development working side by side with clients really to understand their needs, as well as develop use cases on our platform and tools, and make sure we are able to deliver on those. And then we work closely with the CDO team, the global CDO team on best practices, what patterns they're seeing from an architecture perspective, and make sure that our platforms really incorporate in that stuff. And if I recall, the data science lead team is pre-sales, correct? Yep, well it could be post-sales. It could be post-sales, okay. It really depends on the client. So it could be prior to them buying software, or after they bought the software, if they need the help, we can also come in. Okay, so it can be a four pay service, is that correct, or? Yeah, it can be four pay, or sometimes we do it based on just our relationship with the client. And it's kind of a mix then, right? And okay, so you're learning, the client's learning, they're obviously good customers, so you want to treat them right. Now how do you guys work together? Maybe Caitlin, you can explain the two organizations. We're often the early testers, early adopters of some of the capabilities. And so what we'll do is we'll test, we'll iterate, we'll prove it out at scale internally, using IBM itself as an example. And then as we build out the capability, work with Carlo and his team to really drive that into product and drive that into market. And we share a lot of client relationships where CDOs come to us, they want advice and counsel on best practices across the organization, they're looking for latest AI applications to deploy in their own environments. And so we can capture a lot of that feedback and some of the market user testing, prove that out using IBM as an example, and then work with you to really commercialize and bring it to market in the most efficient manner. So you were talking this morning, you had a picture up of the first CDO event, no internet, no Wi-Fi in the basement, love it. So how has this evolved from a theme standpoint? What are the patterns that we should be looking at? So when we started this, it was really in response to primarily financial services sector regulatory requirements, trying to get data right to meet those regulatory and compliance initiatives, defensive posture, certainly weren't driving transformation within their enterprises. And what I've seen is, couple of those core elements are still key for us, so data governance and data management and some of those security access controls, those are always going to be important. But we're finding as CDOs more and more have expanded scope of responsibilities within their enterprise. They're looked at as a leader, they're no longer sitting within a CIO function, they're either a peer or working in partnership with, and they're driving enterprise-wide initiatives for their enterprises and organizations, which has been great to see. So we all remember when Hal Varian declared data science was going to be the number one job and it actually kind of has become. I think I saw somewhere, maybe it was in Glassdoor, it was anointed that the top job, which is kind of cool to see. So what are you seeing with customers, Carlo? You guys, you have these blueprints, you're now applying them, accelerating different industries, you mentioned healthcare this morning. What are some of those industry accelerators and how is that actually coming to fruition? Yeah, so some of the things we're seeing is, speaking of financial clients, we go into a lot of them, we do these one-on-one engagements, we build them from custom, we co-create these engineering solutions on our platform, and we're seeing patterns, patterns around different use cases that are coming up over and over again. And the one thing about data science and AI, it's difficult to develop a solution because everybody's data is different, everybody's business is different. So what we're starting to do is build these, we can't just build a widget, that's going to solve a problem, because then you have to force your data into that and we're seeing that that doesn't really work. So building a platform for these clients with these accelerators, which are a set of core code, source code, notebooks, industry models and terms, as well as dashboards, that allow them to quickly build out these use cases around churn or segmentation and some other models, we can right out of the box provide the models, provide the know-how with the source code, as well as a way for them to train them, deploy them and operationalize them in their organization. That's kind of what we're doing. You prime in the pump. Prime in the pump, we call them, right now we're doing client aids for our wealth management and we're doing that for FSS and they come right out of the box of our CloudPak for data platform. You can quickly click an install button and in there you'll get the sample data files, you get notebooks, you get industry terms, your governance capability as well as deployed dashboards and models. So talk more about CloudPak for data, what's inside of that? CloudPak for data is a collection of microservices and it includes a lot of things that we bring to market to help customers with their AI journey. Things from data ingestion collection to all the way to AI model development from building your models to deploying them to actually infusing them in your business process with bias detection or integration. We have a lot of capability part of the platform. So it's actually tooling. It's not just sort of how-to PDFs, is that right? No, it's an entire platform. So the platform itself has everything you need in an organization to kind of go from an idea to data ingestion and governance and management all the way to model training and development deployment and to integration into your business process. Now, Caitlin, in the early days of the CDO, you saw a CDO emerging in healthcare, financial services and government. And then now it's kind of gone mainstream to the point where we had Mark Claron who's the head of data enablement at AstraZeneca and he said, I'm not taking the CDO title. Because I'm all about data enablement and the CDO title has sort of evolved. But what have you seen? It's clearly gone mainstream. What are you seeing in terms of adoption of that role and its impact on organizations? So a couple of trends has been interesting both domestically and internationally as well. So we're seeing a lot of growth outside of the US. So we did our first inaugural summit in Tokyo in Japan. There's a number of data leaders in Japan that are really eager to jumpstart their transformation initiatives. Also did our first Dubai summit in Middle East and Africa. I'll be in South Africa next month at another CDO summit. And what I'm seeing is outside of North America a lot of activity and interest in creating and enabling a CDO-like capability data leader-like. And some of these guys I think are going to leapfrog ahead. I think they're going to just absolutely jump ahead and in parallel those traditional industries, there's new federal legislation coming down by year-end for most federal agencies to appoint a chief data officer. So Washington DC is hopping right now. We're getting a number of agencies requesting advice and counsel on how to set up the office, how to be successful. I think there's some great opportunity in those traditional industries and also seeing it outside the US and cross nontraditional. So when you say jump ahead, you mean jump ahead of where maybe some of the US best practice. Absolutely, absolutely. And I'm seeing a trend where a lot of CDOs are moving. They're really closer to the line of business, right? They're moving outside of technology, but they have to be technology savvy. They have a team of engineers and data scientists. So it's really an important role in every organization. And I'm seeing it for every client I go to, it's a little different, but you're right. It's definitely an up-and-coming role and it's very important for, especially for digital transformation. This is the, go ahead. I was going to say one of the ways, you know, our teams really partner well together, I think is we can source some of these in terms of enabling that acceleration and leapfrog. What are those pain points or use cases in the traditional data management space, the metadata. So I think you talked with Steven earlier about how we're doing some automated metadata generation and really using AI to, instead of manually having to label and tag that, we're able to generate about 85% of our labels internally and drive that into existing product that Carlo's using and our clients are saying, hey, we're spending hundreds of millions of dollars and we've got teams of massive teams of people, manual work, and so we're able to recognize it, adopt something like that for us internally and then work with you guys to bring it to market. Yeah, absolutely. I think of every ETL developer out there that has to go figure out what this data is. If you have a tool, which we're trying to incorporate in the platform, based on the guidance from the global CDO team, we can automatically create that metadata, automatically ingest it and provide it into a platform so that data scientists can start to get value out of it quickly. So we heard Martin Schroeder talk about sort of digital trade and public policy and he said there were three things, free flow of data, unless it doesn't make sense, like personal information, prevent data localization mandates and then protect algorithms and source code, which is an IP protection thing. So I'm interested in how your customers are reacting to that framework. I presume the protect algorithms and source code, IP, that's near and dear. They want to make sure that you're not taking models and then giving it to their competitors. Absolutely, and we talk about that every time we go in there and we work on projects. What's the IP? You know, how do we manage this? And what we bring to the table with the accelerators is to help them jumpstart them. Even though it's kind of our IP, we create it, but we give it to them and then what they derive from that, when they incorporate their data, which is their IP and create new models that's then their IP. So those are complicated questions and every company is a little different on what they're worried about with that. But many banks, we give them all the IP to make sure that they're comfortable, especially in financial services. But some other spaces, it's very competitive and they're not as worried about it because it's a known space. A lot of the algorithms we use are all open source. They're known algorithms. So there's not a lot of problem there. But it's how you apply them to get insights. That's exactly right, how you apply them in that boundary of what is IP, what's not, it gets kind of fuzzy. And we encourage our clients a lot of time to drive that for the organization. For us internally, GDPR readiness, it was occurring at the business unit level, functional area, we weren't where we needed to be in terms of achieving compliance and we as a studio office took ownership of that across the business and got it where we needed to be. And so we often encourage our clients to take ownership of something like that and use it as an opportunity to differentiate. Yeah, and I talk about the old-time clients. Their data is important to them. Training models with that data for some new, making new decisions is their unique value prop in their IP. So we encourage them to make sure they're aware of that. Don't just throw their data in any canned service out there, model, because they could be given away their intellectual property and it's important to understand that. So, I mean, that's a complicated one, right? The IP piece. And the other two seem to be even tougher in some regards, like the free flow of data. I can see a lot of governments not wanting the free flow of data, and then the client is in the middle. They're like, hey, the government is going to adjudicate. What's that conversation like? The example that he gave, or maybe it was Interpol, if it's information about baggage claims, you can use the blockchain, encrypt it, and then only see the data at the other end. So that was actually a good example. Why do you want to restrict that flow of data? But if it's personal information, keep it in country. How is that conversation going with clients? Those can involve dependent on the country, right? And where you're at in the industry. Yeah, but even some Western countries are pretty strict about that stuff. Absolutely, and this is why we've created a platform that allows for data virtualization. We use Kubernetes and technologies under the covers so that you can manage that in different locations. You can manage it across a hybrid of data centers or a hybrid of public cloud vendors, and it allows you to still have one business application and you can kind of do some of that separation and even separation of data. So there's an approach there, but you got to do a balance, you got to balance it between innovation, digital transformation, and how much you want to govern. So govern is important, but for some projects we may want to just quickly prototype. So there's a balance there too. Well that data virtualization tech is interesting as it gets to the other piece, which was prevent data localization mandates, but if there is a mandate and we know that some countries aren't going to relax that mandate, you have a technical solution for that. An architecture that will support that, yep. And that's a big investment for us right now and we're doing a lot of work in that space. Obviously, with Red Hat you saw our partnership or acquisition that. So that's been. Red Hat, yeah, I heard something about that. Yeah, that's important for us. That's a big part of chapter two. All right, we'll give you the final word, Caitlin, on the spring, I guess it's not spring, it's technically the summer CDO event. No, it's been a great first day. So we kicked off today, we've got a full set of client panels tomorrow. We've got some announcements around our metadata that I mentioned, risk insights is a really cool offering we'll be talking more about. We also have cognitive support. This is another one our clients said they really wanted to help with some of their support back in systems. So a lot of exciting announcements, new thought leadership coming out. It's been a great event and looking forward to the next day. Well I love the fact that you guys have tied data science into the C-suite role. You guys have done a great job, I think better than anybody in terms of really advocating for the chief data officer. And this is a great event because it's peers talking to peers, a lot of private conversations going on. So congratulations on all the success and continued success worldwide. Thank you so much, thank you Dave. All right, you're welcome. Keep it right there, everybody. We'll be back with our next guest. We're ready for this short break. We have a panel coming up. This is Dave Vellante, you're watching theCUBE from IBM CDO. We'll be right back.


how did you advertise on tv it was only through sports was the content integrations again this we did you know we did our spot buys in a in a in a sort of fashion that that made our requirements and i give you an example apart of course from the live match fcp is that you know the spot price that you do we also kind of bought spots what we call as a closer to the match because and we actually made commercials that can suit that particular spot and we scheduled it according to that okay so it was a very it was a very you know holistic plan that we followed it was not that you know we will buy 10 spots and we will run whatever ads we had we actually had pre-show we had closer to match we had live we had meet we had post and we actually had different ads that from the cricket or the context of the match at that point of time will make sense to the audience small example right closer to the match means like before the first ball is bold right now if you can build an ad that actually or the visuals of which actually resembles that the match is about to be started or about to get started right people connect to it because they are at that you know at that point of time in that mindframe right so that's what we tried to do uh toss is a beautiful example right toss is a beautiful example yes yes uh we knew from our research that a lot of a lot of fantasy players kind of look for that toss right because they get a sense of basically what is the pitch look like with the playing game and yeah it could be very effective they want to listen to the captains one and so forth right we kind of basically do one um ad just before that toss ad which looks like a actual toss yeah kind of creates a lot of interest in the user and they kind of take a pause and and look at your ad as you basically that's the actual match and then that was very effective actually yeah overall it just makes you know things for entertaining because they end you know it's entertainment that people see so our ad experience or journey was also you know we tried to make it as entertaining as possible I think I think one of the advantage of the sport aje aje um fantasy company um we get is we kind of basically have that closer partner for sport advertisement right so there were bicycles there were motorcycles basically who were who were doing or basically there is basically soap ads on on on basically live cricket match yeah but as a fantasy company um our integration with a sport is very very natural yeah yeah sports advertisement is a very very natural to a fantasy company compared to other company actually so we have the rivers to basically use the sport content very very effectively to reach as many users as possible 60 days of continuous cricket right and that that again that format itself fits into the into the you know the scheme of fantasy very well so yeah because you have to be at it for that long even in a fantasy correct you you actually get a chance to engage or the users rather get a chance to engage with the with the sport on the platform for a very long time otherwise you know once there is three matches and then there is you know a long gap there is chance that player will lose interest and in this last title our endeavor was to take the play with champ and the proposition of of of my 11 circuit to as many people as possible right and and that's that was the problem treatment which you are trying to take again um iqbal 2020 cricket is such a you know heavily consumed and unloved game um and that it will be happening in india for short this time iqbal 2021 is going to be as big as 2020 so in spite this despite the lockdown restrictions and all right and therefore you know it will continue to be that attractive property for for a lot of advertisers there is no talk about that just to add what abhig said right the intention and the objective are always because as abhig said basically we are one year old brand to create brand awareness and brand recall right by by this massive reach of of tv basically right because if you look at basically tv and fantasy uh live cricket and fantasy the target segment has a hundred percent overall right yeah so so our objective was very simple just create basically a brand awareness and brand recall and and tv tv really helped us


Saying TikTok's not for you is like saying you're not going to do the internet in the 90s. It's kind of unbelievable to be sleeping on it at this point. As we were going through like the data of Instagram, it became clear to me like you would never want second place, right? And so if the social media platform is unequivocally in second place and it's chasing one, we should be on the one it's chasing. TikTok, whatever's working there, is being stolen on Instagram. And so if it works at the source, then Instagram will repeat it within like a week or two weeks. And so I was like, I bet you we could get really good at being like if this audio is trending on TikTok, I want to know how long will it take before it's trending on Instagram. Sure enough, it was like two weeks. Which means we're like from the future, we're like buying time.


Godfrey Logpabio, the son of president, says the national assembly under his leadership will give all necessary legislative barken to the removal of petrol subsidy by the president, Paula Tinnabouf. Speaking during his acceptance speech, Apabio said the terms assembly will be forward and ensure that legislative barken is given the policies and programs of the president. I want to play with you the single standards to permit me to offer special commendations to the president commander-in-chief of the armed forces. For the bold step we have so far taken, particularly in the issue of subsidy, if it requires legislative barking we shall give. We must begin to produce one fuel in Nigeria. We must begin to encourage production of diesel and others in this country. And of course if the stories so far are true that we used to have 69 million barrels a month and we are now having about 13 or 15 million barrels, that will show that we were subsidizing all the consumption going on in our neighboring countries in which we can no longer continue with our very lean resources. So we applaud the federal government for the first steps. We will try our best to also make laws that will move forward and encourage foreign direct investment into the country. The current administration has brought about the acronym of renewed hope and I think this Senate will join in ensuring a total renewal hope for Nigerians where they seem to have been no hope. I had the opportunity of serving as a governor and I want my people who work with me that I do not still believe in politically motivated infrastructure. Therefore the 10 senators of the federal republic of Nigeria will ensure very serious oversight functions. We shall carry out very serious oversight functions to make sure that we do not waste the resources of the country. We will put members of the executives on their toes, particularly the ministers, when they are ready to work, when they are appointed. We will follow the project. Fresh news updates


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.  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 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 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.  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.  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.   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.  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.