 Good morning, everyone, and welcome to the Open Source Summit North America 2020. We are happy to have you all here today and wish that you were all with us in person. But since that's not possible, here we are. We do have a great event planned for you this week, and the virtual model has actually allowed us to gather a lot more people, 4,000 folks from over 103 countries. We are so excited to have you here. And the amazing content that we have today is the reason you're all here. A big thank you to all of our program chairs, committee members, and everyone who did an amazing job this year. Thank you for all of your efforts. Before we get started, I would like to thank our sponsors. A special shout out to IBM, our Diamond sponsor this year. We are grateful for your support, in particular during this difficult year. I'd also like to thank our Platinum sponsors, Google, Red Hat, Suze, Cloud Native Computing Foundation. Thank you so much for all of your support. And again, to all of our sponsors, we are extremely grateful to have you all here. So this has been a difficult year on so many levels for everyone around the world. And the Linux Foundation and the open source community are no exception to that. And before we get started on our event, I just want to thank all of the people who supported us during these tough times. We're so grateful to be a part of an amazing set of communities who have come together when the going has got tough all around the world. When the pandemic hit, our first priority was the health and safety of our staff and communities. And our second priority was to make sure that we could manage the calamity and financial exposure of having to wind down dozens and dozens of events all over the world. I want to give a shout out to our event team who helped facilitate today's event, in particular, I want to thank Angela Brown, who's the head of our event team, Stephanie Weigel, who's the head of our finance team for all of the work that they did tirelessly working to unwind all of the different contracts and venues and catering and all of the dozens and dozens of events that span thousands of people all over the world. It has been a tirelessly hard effort over the last few months, but we've been able to really shore things up. Our next priority as an organization, aside from dealing with winding down our events, was to make sure that we kept all of our folks at the foundation busy. As many of our event industry peers were being laid off, we were training our staff to work on other parts of our business to make sure we could keep them all busy and employed. And boy, they really have stepped up. I just want to thank that entire team. We're so proud of all the work they do. And hopefully our communities can see the impact that those folks have had. I'd like to also thank our sponsors, boards of directors, members and community members who've helped us through this time, through working with us on so finally, once we've stabilized our organization, restructured the way we run our events, we asked ourselves at the foundation how we can help. And so what we've been doing over the last few months is looking for quiet ways where the Linux Foundation can help in this global crisis. The first thing we did was we expanded our mentorship program to provide opportunities for folks who've been displaced from their jobs. I want to give a particular shout out and thank you to Melissa Evers Hood from Intel, who started off and contributions that are now totaling over 350,000 with a $250,000 donation to sponsor more mentees to come through our summer mentorship program. In addition to expanding our mentorship program, our open mainframe project introduced a COBOL training course. This may be surprising to some, but many of the unemployment systems throughout the United States haven't been updated in a while, and were written in COBOL and required a series of maintenance in order to cope with increased traffic on those systems as unemployment in the United States soared. And we're really proud of the open mainframe project for helping with that. The virtual event pivot, we went and evaluated 65 virtual event platforms. We are going to, when they say, you know, when life gives you lemons, make lemonade, we are going to actually make virtual event platforms a part of all our future physical events as well. So we're happy to have gone through that process, and now we'll be able to reach so many more people in the future, even as we get back into physical events. This week, we have some things that can help folks out. A technical resume writing and Ally workshop on Thursday. Check that out. And then finally, we are going to be bringing the power of open source to help directly camp combat this pandemic. Dan Khan who recently left his role in the cloud native computing foundation as their executive director will soon be launching a new Linux foundation initiative, the Linux foundation public health initiative to help public health authorities use open source to fight COVID-19 and other epidemics. So we're really, really grateful again for all of the work from our staff, from our communities and from our members to come through together and help in this very difficult and challenging time. Next, I want to thank and welcome all of the end users that are attending the event today. We were very impressed that there really has been a shift across the industry when it comes to open source from technology companies and individual discoverings, serving projects to now really big end users joining our community. And we've seen a huge increase in the number of folks really are not traditional tech companies, but end users of technologies joined in events like this, all helping accelerate the adoption of cloud native. These developers at their companies are finding open source tools they need to help them do their jobs and convincing their companies to invest. And so to all those end users that are here today, we want to welcome all of you and hope you enjoy the event. We have a few more announcements. Today we're announcing our 2020 lift training scholarship recipients. Since 2010, the Linux Foundation has awarded hundreds of scholarships for millions of dollars worth of specialized technical training to those who may not have the ability to afford this kind of opportunity otherwise. This year, the Linux Foundation awarded scholarships to 500 of the more than 1200 applicants who vie to be selected in one of 10 categories. This year's selected pool of talent represents the potential for great season tech professionals who will receive this year's scholarship and be able to work across our open source communities. Next, we have a special announcement about our SPDX standard. SPDX is a specification that helps to track open source software and really any software for that matter across the software supply chain. And today we're announcing that the latest version of SPDX, it will be the second Linux Foundation standard submitted to ISO JTC-1 for approval as an international standard. The Linux Foundation is a ISO pass submitter and has been able to take our projects from open source repo to international standard through this process. And we're very excited that SPDX has become the second specification that we're submitting to ISO for international standardization. Next, I'd like to announce our JDF community specification. At the Linux Foundation, we're making a lot of strides towards working on standards development, combining the best of open source and the best of open standards to extend the reach and usefulness of open source through standardization for interoperability and more. The JDF joined the Linux Foundation about a year ago and has brought its successful program of streamlined project setup, governance, and standards to develop for our greater community. Today we're announcing the latest innovation coming from the Joint Development Foundation, the ability for the JDF and the LF community specification program to incorporate terms, procedures, and templates required for the development of technical standards. It provides contributors an easy free repository based approach for specification development. This will be the simplest and quickest way for a collaborative effort to start this journey to becoming an internationally recognized standard. It allows technologists to collaborate with very little overhead and to succeed and grow all with the seamless support of the Joint Development Foundation behind them. Next, we want to announce our Open Network Automation Platform Frankfurt release. This is the sixth release of the Open Network Automation Platform, and it furthers the Open Network Automation Platform's position as the comprehensive platform for orchestration, management, and automation of network and edge computing systems. ONAP is really the de facto standard for the world's global network operators, cloud providers, and telecommunication providers, and we're very proud of their sixth release. Next, we have a new announcement of a project in our AI Foundation. It was announced last week that Databricks Spark at Databricks Spark and AI Summit that they were donating ML Flow project to the Linux Foundation. ML Flow's mission is to provide a platform for machine learning, lifecycle, management, and more. It includes experimentation, reproducibility, and deployment for machine learning applications. Since its introduction two years ago, ML Flow has experienced an amazing growth in its community. With over 200 contributors joining, it has been downloaded more than 2 million times a month and has a 400% annual growth rate in the amount of downloads and usages we're seeing out there. Databricks made the choice to bring ML Flow to the Linux Foundation so that they have a vendor neutral place with an open governance model to help broaden the contribution to ML Flow and make that project grow even more. We're very excited to have them here. Last but not least, we have an announcement that didn't make it with a slide for the cutoff, but it's worth mentioning the Confidential Computing Consortium is announcing today that they have grown their membership over 60% in the last nine months. The Confidential Computing Consortium is dedicated to finding and accelerating the adoption of Confidential Computing. New members announced Looks like we lost Jim. My name is JR Stormant. I'm president of the Phenops Foundation and we were also he was I think announcing at that moment that we are going to be joining the Linux Foundation as well. So we're excited to do that a little bit about why we're here. So it used to be that when a platform team needed to get access to hardware, pre-cloud, they would need to go to their procurement team. And the procurement team would work with them on a business case and eventually they would get the money they need for resources. And this process involved essentially engineers as requesters and finance and procurement teams as approvers. And this process took a while. Long procurement cycles and high cost of engineering product projects of failure. So in the DevOps world right now you've got all these individual service teams who are going to their procurement teams making these business cases in order to get the money. So this process unfortunately takes a long time or took a long time until cloud came into the play right now engineers are writing infrastructure as code in order to instantly get access to the resources they need. So this is really great in a lot of ways for engineering teams to move more quickly for projects to be more dynamic. But the business folks and the finance procurement teams have less visibility and spend is often has a lot more waste involved. So FinOps is essentially an operating model for this world of cloud where we're bringing together a prescriptive set of actions, best practices and culture that enable these teams, these disparate teams like engineering teams, finance teams, IT and business teams to come together to get the most value out of every dollar that they spend in cloud. So when FinOps is implemented organization, you have a much better model where these engineering and finance IT teams are all working together as one to get that instant procurement of resources that cloud delivers, but also to ensure that you've got predictable costs and budgets with a low cost of failure. So the FinOps foundation, which will be joining the Linux foundation this month, has three primary goals as its mission. The first is to be the central community for cloud financial management. We host a lot of virtual events. We have a very active meetup community and Slack community. And we're doing all this to the second point to advance the careers of FinOps practitioners. A lot of our members are engineers, a lot of them are in finance, a lot of them are in IT. It's a diverse group with a lot of different titles, but they're all working to get better at cloud financial management. So we offer training certification career development there. And the third piece, which we're really excited to collaborate with the Linux foundation on is to start to open source a lot of the standards and best practices that this group has pulled together. The foundation launched about a year ago, and we've had some really great growth in that time. We have over 1500 members now representing companies of giant enterprises and tech unicorns all around the world. And we've taken a lot of the best practices that these companies and individuals have shared and put them together into resources like the O'Reilly Cloud FinOps book, which launched early in the year, as well as a certification and a number of other things. We're very excited also to announce today that thanks to the Linux foundation's training team, there's now a free intro to FinOps course available on edX. So we're excited to be part of this new growth, the team at Linux foundation has been massively helpful. A big shout out to Chris Anizek from CNCF for all the support in this process and looking forward to growing with this community. Thanks so much. Jim, can you hear? So I think I'm all done here. Thank you very much there, JR. And we are happy to have you on board. Thank you. Our next announcement, we are introducing the Soda Foundation, previously open SDS. They are expanding to include both open source software and standards to support an increasing need for data autonomy. The Soda Foundation hosts an open source unified autonomous data management framework for data mobility. Hi. I think we lost Jim. Hello everyone. Good morning. I'm Stephen Tan, the chairman of Soda Foundation. All data challenges are demanding and that is the purpose of Soda, to bring a community of people together to address these challenges. Let's take a look at some examples. This is Toyota connected car platform. It needs to handle massive amounts of data comprising videos, sensor data, and map data. So there are many requirements for this platform. For instance, we need data lifecycle management to manage the flow of data from tier one storage to tier two storage and from tier two storage to cold storage and to the clouds. This platform also requires other stuff like data integration and data security and so on. And there are many challenges on this platform this big. For example, how do you avoid data silos and data fragmentation? How do you prevent vendor lock ins in terms of the software, the hardware, and the cloud? And how do you integrate everything together and make them work together seamlessly? Toyota is a member of the Soda EUAC, the end user advisory committee. The committee is a mix of companies from different regions and industries. It serves as a forum for users to share their ideas, your challenges, and use cases. When Toyota shared their use case, many other members actually mentioned that they faced the same issues. So what we are hoping to do in Soda Foundation is actually by bringing these users together, we can address these issues better. The Soda Open Data framework is an idea that came off from the user's input. The idea of this Open Data framework is to actually try to address the many issues or users' cases of our users. The goal is to let users build end-to-end solutions easily. And the framework connects data end-to-end from platform and applications down to storage, from edge to core to cloud. And it connects all the, and it manages all the data in between, and takes care of things like data protection, data lifecycle management, and so on. This framework is open source, and it allows vendors to integrate easily. So the vision is actually to deliver a highly autonomous data framework to improve operational efficiency. And to do that, we need to do infrastructure integration, integrated data management, and then finally the autonomous data management. Currently, we are developing a mix of one and two, and the result is the Soda Ferro release. Soda Ferro release is the 1.0 version of the Open Data framework. Ferro addresses what I call the ABCs of data challenges. A is the annoying challenge, which is the platform. Whenever there's a new platform, many things in the infrastructure needs to change to interface with this new platform. So with this framework, what we do is that the Soda plugin is the only thing that interface with the platform. So if there's anything that changes in the platform, or if there's a new platform, all that thing that needs to change is the plugin, and everything else in the infrastructure can stay the same. Next is the boring challenge. Which is the storage piece down below. Nobody likes to deal with storage. So what we've done is that we have abstracted storage to make it easy for platforms and applications to consume as a service. And the last challenge is the common challenge that every user faces. And this is the multi-cloud piece. Every user has a multi-cloud strategy right now. And this framework provides a single interface to connect to the different public clouds. And you can do things like migration across different clouds, and data life cycle management across different clouds too. So Soda Ferro has many other great features. And it's available today on our GitHub for download. Soda Foundation is also trying to foster an ecosystem of software for data autonomy. And today I'm happy to announce that China Unicorn has donated an in-house project to Soda Foundation. It is a massively scalable object storage project that's storing about four petabytes of production data in China Unicorn. And to help the growth of YIG and other projects, what we are doing is that we are creating a Soda Incubator program to accelerate its development and also adoption. And we welcome other projects to join Soda Foundation too. As Jim mentioned, Soda Foundation is a transformation of the OpenSDS project. The companies you see here came together to help with this transformation. And I'd like to thank each and everyone of this company, and especially the Premier members, China Unicorn, Fujitsu, Huawei, Entity Communications and Toyota Motor Corporation. I'm grateful today to be given this opportunity to announce the launch of Soda Foundation. The picture you see here is of the soft launch in Tokyo last December. So without this community of people, this would not be possible. I'd also like to thank Jim, Dan Kahn, Mike Dolan, Etto Sanau Advisor, and many other folks at Linux Foundation for helping to make this a success. Thank you very much. Thank you, Jim. All right. Thank you, Stephen. And we are very grateful to have you as a part of the Linux Foundation. Next, I would like to introduce someone who just joined the Linux Foundation as the Executive Director of our Cloud Native Computing Foundation. I'd like to take a few minutes to have Priyanka welcome to the LF and to introduce herself. Priyanka, welcome. Thank you so much for having me here, Jim. Hello, everybody. I am so excited to be here. This is my first speaking opportunity since taking the helm at CNCF or the Cloud Native Computing Foundation. You'll see here in my slides the name tag. It's funny because back in the day when I'd go to conferences or meetups, I'd be like, oh, I have to fill this again. And now in the new reality we all face, it's like, when will I get to do this again? So, as Jim said, I am taking over at the CNCF. If you ever want to reach me, please feel free to find me on Twitter. This is my handle here, Priyanka. I spend a lot of time on Twitter and my DMs are open, so I always welcome a conversation. Also, I'll be hanging out on the Slack for this event for the major part of the day today. So please do reach out, say hi. If you have any ideas you want to talk about or any thoughts, just want to catch up. I'm very, very open. All right. Let's see. All right. So, for most folks, the Cloud Native Computing Foundation is a household name at this point. Just as a refresher, it hosts critical components of global technology infrastructure. It started off with our flagship project, Kubernetes. And today has a lot more to offer. In addition to Kubernetes, there are many more household names in the foundation such as Prometheus, Fluenti, Yeager, Envoy. The list goes on. CNCF brings together the world's top developers and users and vendors and runs the largest in-person open source developer conferences. I think most folks are familiar with the KubeCon, Cloud Native cons that happen. The CNCF is, of course, a part of the Linux Foundation, and hence why I'm here. I'd like to give folks a very quick background on my journey so far. I started my career at Google many years ago and had a pre-Cloud Native part of life where I worked in tech but in different areas. Then the startup bug bit me and I ended up working on developer tools which I instantly fell in love with and I knew that anything I do further must be closed to software development and infrastructure. I had the opportunity to work on the Open Tracing project which was the third project to join the Cloud Native Computing Foundation in 2016. That was a special fun time. Everything was new and we were talking about things like what are microservices? What is container orchestration? What is Kubernetes? A lot has changed since then, of course. After participating in the ecosystem as an educator contributor with Open Tracing, when I joined the company GitLab, I was elected to serve on the CNCF governing board. That was a really useful experience for me because I got to see how the leadership, Dan Kahn and Jim and Chris ran this massively impactful organization. Having had that experience when I was called upon to lead Cloud Native Computing Foundation, it was a true dream come true. A major thanks to Jim Zemlin, Dan Kahn and Chris Anistek for seeing the possibility and bringing me on board. I am very thankful and I'm so happy that I get to be Cloud Native 100% of my time now. So how has the CNCF been doing? We all hear about all the projects. We hear a lot. But what are the numbers like? Well, I'm so happy that I get to tell you. We have 571 member companies, 144 of which are end user members. That is a special aspect of pride for us. We actually enjoy the largest end user member community of all foundations. And that is really useful and important because, as Jim said when he was speaking, there is a shift where end users are getting deeper and deeper involved. They are taking on bigger technology decisions. They're building cool projects and the more representation and involvement we have, the better. We have 28 graduated and incubating projects, which I've already told you some of the star names. We are always looking for amazing technology that can benefit our ecosystem. So if you are ever thinking about a project that needs a neutral home with good governance and support from an experienced staff, please consider us. Actually, it's a matter of pride for me that just last week, the Technical Oversight Committee was able to approve 11 projects for our sandbox, which helps those projects have a neutral space where different companies can come collaborate. It's awesome. And the final result I would like to mention is just that KubeCon. They are the largest open source conferences in physical conferences in the world. And I am so excited for all the work we are all doing now to pivot to virtual and then eventually when we'll all get to be together again in person in some awesome location. But as Jim said, with a virtual component. So what lies ahead? Dan and Chris have done an amazing job for CNCF and we all stand on the shoulders of giants. What lies ahead is also exciting. It's the second wave of cloud native. As I mentioned, there's a deepened focus on end users. We want to work with them as much as possible to help them, support them, enable them. There are many initiatives that are coming out. My colleague Cheryl Hung, she has just released the end user tech radar, which gives great advice to folks on what projects are good and what people are experiencing, not just project, but technologies in cloud native are performing in end user experiences. So these are deeper insights. We're also, as I said, always looking for amazing projects that can help the ecosystem and keep building upon this amazing platform that we have. As I said, the sandbox process has iterated and there are lots more constantly working. So what is true today will be new and improved tomorrow and then onwards. It's always be iterating. In this bright future, of course, virtual community building is a large part of it. And you will see just as open source summit today, KubeCon EU has gone virtual and is going to be held in August. I highly recommend you folks come me and my team, the folks who have built this event, we're all working together to give you the best experience possible. So I just wanted to call out who are we? At the end of the day, the CNCF and largely the Linux foundation as well, we're foundation of doers and builders. We can that's what we all have in common together. I would say we're all team cloud native. I encourage you to keep this mindset as you, whether you're getting started with Kubernetes, whether you're a veteran who has deployed to Kubernetes many times who uses on by who has all the complexities, no matter what stage you are, no matter whether you're a contributor, you're a maintainer, you're an end user, you're a vendor. We're all in this together. We're all team cloud native. And with that, I would just like to say, please do consider coming to our virtual booth here at open source summit. And then I really want to see you all at KubeCon cloud native con virtual just FYI, before I drop, my colleague Caitlin Reymor will be speaking to you tomorrow. And you can learn a lot more about how cloud native technologies impact end users when she bakes sourdough with end user of interest. So that's all for me. Thank you so much for having me. And thank you, Jim, for giving me this opportunity. Gabb Gade Colombro. He is the Executive Director of FENOS. For those of you who may recall, the FENOS foundation was announced as a new Linux foundation project last month. Today, Gabb is here to tell us about the FENOS foundation. Welcome. Thank you, Jim. And thanks everyone for having us here. I'm really excited. This is my first time here at the open source summit. So really, again, thanks everyone for attending and thank you, Jim, for the opportunity. Before we get started, a little bit of disambiguation. I'm really excited to have heard the FENOS foundation being launched. We are FENOS, just to make sure you guys are not confusing with the names. So many projects in the Linux foundation, they were running out of names. Second point I want to make is open sourcing financial services used to be almost an oxymoron until a few years ago. And that was certainly my initial reaction five years ago when I had the honor to be called to run the FENOS foundation. But the truth is the banks have been consuming open source for the longest time. And not only consuming, but over the last few years, we've seen major inroads towards contribution. We're proud to feature the Goldman Sachs contribution last year, a huge contribution of their logical modeling platform. We are seeing increased contribution from giants like Morgan Stanley, JP Morgan, CD, in our foundation. And even TechCrunch is looking at the next Fintech decade being completely different from what we've experienced to date. There's an interesting article that got published just a couple of weeks ago from our Gold member, Red Hat, talking about how banks should contribute to upstream. And we really exist to create new upstreams in financial services. And so over the last four years, I'm really proud and thankful to our community to have come together in a very complex industry like financial services with very specific requirements around compliance, really through the hump of contributing to open source. You've heard Priyanka, you've heard Jim talking about end users. We have been an end user focused foundation from the get go. I want to send a special shout out to our Platinum members, of course, provide us the support to continue growing their foundation. Over the last four years, we've built about 40 active or incubating projects. We have a community of over 300 contributors. And I think what I'm mostly proud of is the cross pollination that we're seeing between tech companies and financial services institutions. And so before we move forward, why is that? Why is this industry looking at open source very much like any other industry has done as you folks know over the last 20 years? Well, I think there are three main reasons here. The first one is financial services has experienced starting 2010 a shrinkage of their margins. Some data research firm says that about 39 billion less revenue in the top line has been since the 2010 crisis. That's almost like JP Morgan and Goldman Sachs would just disappear. And from the bottom line standpoint, regulatory spending has increased drastically over the last 10 years. Again, so effectively, there's not enough or infinite amount of money to continue throwing at software problems. And that's where open source can play a really key part. The second point is, again, talking about tech vendors and users in this industry, the line is skipping on getting more and more blurred. Every financial institution is increasingly looking at behaving and running their business as a technology company. And that means not only bringing in all the tips and tricks from here from the West Coast, but also getting over the hump and the complications of being a regulated industry with all the access to talent and again, changing drastically the way you run your organization. And then number three, the move to cloud. As we know in the broader community, the way we deliver software and we create business around open source has been drastically changed by the cloud. We are seeing the same process happening in financial services with new business models. And of course, the FinTech Wave creating a completely different way of delivering software and open source is being a huge part in that. But let's contextualizing a little bit when it comes to looking at the financial services stack. As we said, we've always seen open source being part of the financial services stack. And the challenge here is to move from consumption to contribution. And if you look at, if you go and break down a little bit that stack, you'll see that, of course, there's a set of general purpose platform and operating systems that we've been collaborating in the open source community for decades. But there's a whole layer of technology that is very specific to financial services, whether you're talking corporate banking, retail banking, or wealth management, both in terms of integration and data standardization. And that's where the Finos bread and butter is. We think there's huge amount of potential to collaborate in the open. That's why we're very excited to work with Jim and the team to join the Linux Foundation, because with this very powerful partnership, we can actually cover the whole stack and enable firms to also become active upstream contributors. Let me give you a couple of examples. Let's be a little bit more concrete as to what we do in Finos. Over the last four years, we've seen projects originated from financial services companies like our forming project alloy contributed last year by Goldman Sachs, our high throughput data streaming visualization library contributed by JP Morgan, cold perspective, open standards like our FDC three standard, and more compliance specific industry specific projects like our cloud service certification, again, bringing together the need to go to cloud with an open source approach to bring in the regulators into this conversation. So we think there's a huge potential here. And if I look at the broader landscape trying, I'm not going to go through all the projects here, but if you see the combination of our projects in Finos with the upstream, you know, very key components for this industry like electron node and hyper ledger, we can see a huge potential from a project standpoint to grow our communities through cross pollination. Not only that, but of course, we're super excited. What you can see as we join the Linux Foundation as we merge our operations, we're looking to expanding globally, we're looking to bring in the stellar training team from the Linux Foundation to help us certify our projects. We're going to be announcing our joint events a little later in the years to stay tuned here. And most importantly, as I said, we want to enable banks to become conscious upstream contributors. Couple of announcements before I close, we just launched our first beta version of our landscape. If you're familiar with CNCF or LFAI, you know, they have a beautiful landscape of their projects. If you go to landscape.finos.org, that's going to be our landscape moving forward. We welcome and encourage contributions. So please check it out. You got the GitHub link there. And as we look forward, one area where we think we'll play a huge role is what we call open source financial regulation. We think open source can be a third way in the constant struggle between regulation and deregulation in a way that we can bring in the regulators in the conversation and ultimately they could partake to the open source process in actually defining regulation and enforcing regulation. So please stay tuned on this channel. There's a huge opportunity we think to bring together regulators and financial services industry. And so closing, I just want to leave you with that. Whether you're a financial institution, whether you're a fintech vendor, whether you are a regulator, or whether you are just a tech vendor, there's a huge opportunity here. And we're not just talking about, you know, efficiency, cost savings, you know, your typical benefits of open source. We think that as a user and as an end user of the financial services industry, you can help us through open source, make it change also in areas like financial inclusion, ESG, and so many sort of bigger goals that we can achieve through open source. And with that, I want to thank you, Jim, and the whole Linux Foundation team for this opportunity. All right. Thank you, Gab. And again, welcome to the Linux Foundation family of projects. We are so happy to have you here. Our next speakers require little introduction as their fireside chats have become a mainstay of this event. Please welcome Dirk Hondel, VP and Chief Open Source Officer at VMware and creator of Linux and Git, Linus Torvalds. There we are. That was surprising that we had an interstitial. Good morning, everyone. My name is Dirk Hondel. I'm the Chief Open Source Officer at VMware and you are. And I am Linus Torvalds. And this is a very strange new model of doing conferences for me. But let's see how it works. We've had a few technical issues, but this is hopefully going to work fine. Oh, it's going to be wonderful. The lack between the two of us is one of the things I'm most worried about. So Linux 5.a, what a massive RC1. I am surprised. And then as I thought more about it, maybe this is a COVID thing. Are people at home not traveling? They have more time to work on this stuff? I don't know. It might be. But honestly, I think we've for the last three years or so, kernel releases have been fairly stable size wise. And there's been a kind of up and down that has just depending on timing. And I suspect 5.8 might be because of people staying inside, but it might also be that it's just happened that several different groups ended up coming at roughly the same time with new features and 5.8 ended up being surprisingly big for that reason. But the last time we had such a big kernel really was when we let it slip that the next kernel would be an LTS kernel. So there was clearly a reason. And anyway, I mean, obviously we won't know, but I found it fascinating just how big this is. And the RC you did yesterday was also massive. Yes. I mean, that was actually not that unexpected. With a big merge window, I would expect that the first few RCs are also fairly big with people finding problems and fixing issues that they introduced. RC2 usually is pretty small because that's the common period after a merge window. But then RC3 through 5 is when you usually see all the major issues being cleared out. And right now I don't know what will happen. It's too early to tell. This might be one of those releases that because it's large, we will end up having to delay the final release and give it one or two more RCs than usual. But who knows? So far, things have actually been pretty smooth. I'm doing this on my laptop, running RC1 because that's the way I want to work. If I can't trust my own merge window, then I'm doing something wrong. I like your approach to bravery. That's nice. So COVID has obviously been a huge disruptor for a lot of us. And so one of the things that I've been wondering about how this has been for you and your family. This is the first time for me since 1994 that I've been in the same place for four months in a row. My family, I think, is getting tired of me. How is that for you and your family? Well, to be honest, it hasn't changed that much. Literally, this conference right here is the first big change. I do not like doing video conferences. I have not done a single video conference so far during the last four months. And the fact that it seems to be working at all frankly surprises me. But the way I normally work, I work from home. I work sitting in front of the computer reading email. And I'm happy to say that so far, it looks like none of my co-developers have been hugely impacted either. I was actually worried for a while because one of our developers was offline for a month or two. And everybody was kind of wondering what was going on. And it turned out that was just RSI. And RSI is kind of an occupational hazard, but it had nothing to do with the current pandemic. But I mean, one of the things that is so interesting about the Linux community is how much it has always been email-based and remote, how rarely we get together in person. We have a couple of conferences, the key maintainers once a year for the kernel summit. So the only big impact on the kernel community is that you and I can go diving. That may not be the only impact people see, but it certainly is one of them. Yes. So I don't want to make this a political conversation. Obviously, this is about technology. But one of the things that I found striking when I look at the cloud-native community about CNCF, we see a significantly larger share of Black contributors and leaders. Kelsey Hightower, Brian Lyles, Steven Augustus. There are so many of them. And I don't think I'm seeing that in Linux. Is that just me not seeing the right people? Or are we less racially diverse than some younger foundation simply as a function of the time when we all started almost 30 years ago? Honestly, I don't know. I mean, I don't know on two different levels. One is I do suspect you may be correct that a lot of the people who are in low-level technology are the kind of people who started several decades ago. And that's how they got into the whole low-level hardware interfaces and getting into operating systems. But the other reason I don't know is that I literally don't know. I do not meet with these people. For all I know, half of the kernel community could be not white. I never see them. I don't do the face-to-faces. I do know that when it comes to the core maintainers that I meet once a year, we are obviously a very homogeneous crowd. But I don't even know about all the new developers. We have every single release. We have over a thousand developers. Quite a lot of them we have over 2,000. And I do not know what the people involved are or if they are even a people. For all I know, some of the patches being sent out are sent out by artificial intelligences that people are trying out. And here was saying that you were hoping it was dogs because dogs are always nice. Dogs are never evil. Let's move off of that topic. Don't go there. So much of what everyone's talking about. If I look at the last hour of this event, it's all higher up in the stack. Cloud, segment-specific technologies like fintech. So stories of Linux's demise are exaggerated. We continue on. Everything is growing. This continues to be VOS everyone talks about, right? Or kernel, I should say. Well, I'm certainly not seeing anything go away. But at the same time, I do want to say that for the last over decade, I've told people that no, kernels are not the future. That if you're looking for a new exciting project to get involved with, maybe you should not be getting involved with a kernel. I mean, the kind of things we're doing are, I wouldn't say they're the same that people did in the 60s. But the basics of a modern operating system are still reminiscent of what was being done in the 60s. So one of the things I'm still very surprised about is how many people we have and how many new people we get every release and not just people doing new things and new drivers. We are like in 5.8, which is looking to be one of the biggest releases ever. A lot of the changes people are doing is literally very fundamental stuff being cleaned up and fixed and improved. So kernels should be something that you take for granted and that you don't really have to think about. But at the same time, there is a lot of interesting technical work still being done and still going on. And I just noticed that the sun has moved and it's right in my face and I can't see anything. Well, you're certainly well lit right now. So you said there are things that are still interesting. Other times when we talk about this topic, you've said that Linux is boring and that's how a kernel should be. Now, if I look at this question of you, Greg, many of the leaders are all in a certain age range. Many of us have the 5 at the beginning of the numbers, a couple are approaching the 60s. So at some point, we as a community need to start thinking about generational change. So what do we do now? Time out there. A, yes, I've said that the kernels are boring, but I really mean that in the sense that a lot of new technology should be more interesting. To me and to a lot of other people, there is nothing more interesting than interacting at a low level with the hardware and really controlling everything that's going on. So don't get me wrong. Kernels are not boring, but on the other hand, most people should consider them boring. The other thing I also, I don't think it's true that we're getting gray and old. I mean, it is definitely true that the people who have been around for three decades by now, yes, we are getting gray and old. Not so great yet. But again, it really is a lot of it is the fact that people do tend to stay around and the people who have been around for a long time, we have moved into maintenance and management. I don't like the word management because I don't think of myself as a manager, but that is realistically what I am. And a lot of the new people who are not 50 years old and not 40 years old, they are still often in college or just graduated. They are the ones who are often doing the real work. And the fact that we have managers and maintainers who are old and starting to gray, that's, I think, a completely different issue. But do we have a generation of people, let's say in their 30s, who are moving up through the ranks of maintainers so that we have that next wave of people to take over eventually? I mean, look, we've been doing this for almost 30 years, so we need to start thinking the next 10, 20, 30 years. And so we need to have that next generation, correct? We do. And do we have enough? No, it turns out it's really hard to find people who are maintainers. I'm going to try to move a bit of the sun. Maintainership is interesting and it's challenging, but one of the downsides of being a kernel maintainer in particular is you have to be there all the time. Maybe it's not 24 hours a day, but it is every day. You read email, you react to email, you have to just be there. And it's not necessarily a very easy niche to get into. And we do not have enough maintainers. We do have a lot of people who write code. We have a fair number of maintainers. For being an open source project, we have hundreds of people who aren't maintainers. And that's usually more than most projects have participants. But at the same time, the one getting issue we often have is it's hard to find people who really look at other people's code and help funnel that code upstream to all the way eventually to my tree. And that's something which I think we need to continue working on. I mean, we are working on it, but I think it is one of the main issues we have in the whole kernel maintenance tree. And a big part of this is of course that it takes time. It takes experience. You have to have done this for a while as a low level maintainer to slowly move up and gain the trust of enough people, including your trust, obviously. Right. And I think the keyword is the one you mentioned, trust. It's not just trust from other maintainers. It's also trust from all the people writing the code. They need to see that, okay, I recognize this name because he's been around or she's been around for a while. And that just, it takes time. And this is something where 30 years ago when we started, you didn't need that. It was like, you showed up, you were a warm body, go for it, you got the job, right? And getting a very, very warm welcome from you. Yes. Yes. And things have somewhat changed. Part of it is so many more people now depend on the kernel that we can't do the kinds of wild and crazy things that we used to do. And taking patches from you certainly counts. But part of it is also that back when we started, even fairly early on when we were 10 people, when we grew to be 50 people, it's a different kind of situation than when you have 2,000 people every release. And one or two or 200 of them need to stand up and be the maintainer for a subsystem. So switching gears a little bit and talk about technology in this space. And something that comes up every once in a while, and it kind of is related to that generational question is no one writes software and C anymore. So everything, every new project is done in Go or in Rust or in yet another language that I've never heard of. Is there a risk that we are becoming the COBOL programmers of the 2030s? Well, I don't actually think it's true that nobody writes in C anymore. I think C is still one of the top 10 languages easily if you look at any of the statistics. That said, I mean, people are actively looking at, especially doing drivers and things that are not very central to the kernel itself. And having interfaces to do those, for example, in Rust, people have been looking at that for years now. I'm convinced it's going to happen one day. I mean, it might not be Rust, but it is going to happen that we will have different models for writing these kinds of things. And C won't be the only one. I mean, right now it's C or assembly and most people would rather not touch the assembly parts. But it is something that people are looking at. I'm probably the wrong person. Greg has been more involved since he's the driver maintainer in general. But things are afoot and these things take a long, long time. I mean, the kind of infrastructure you need to start integrating other languages into a kernel and making people trust these other languages. That's a big step. Yeah. So to move this even more technical, I haven't worked in computer hardware in a while, working in a software company now. But there was an interesting fun article last month about you building a new computer for at home, an AMD Ryzen Threadripper 64 threads. That sounds like fun. It also sounds pretty loud. Well, I was actually worried about that. It turns out I like my office to be completely quiet. And at the same time, as kernels have grown, especially during the merge window, when I get like, I get hundreds of pull requests and I strive to do about 20 to 30 a day, which is about my limit, just because I need to know what's going on. Usually it's not the technical side that is the limiter here. For me, the limiter is that I need to be able to understand what I'm pulling and what's going on. So I can do roughly 20 to 30 pull requests a day. And that means that during this time, in order to do that, I need a lot of computing power just to do the builds. And I decided my old machine took half, almost half an hour. Well, not quite, but it was over 15 minutes to build a kernel. And I need to operate. And I decided I can deal with a machine that is silent as long as it's idle. So that when I'm reading email or when I'm responding to issues, if it's completely silent during that time, I'm happy. And then if it starts making that whooshing sound when the fans really come on, when I start building, I decided I can deal with that if I can make my builds go much faster. And so far, I've been very happy. In fact, now I'm starting to think I should have gone for the big brother and gone for the full 64 cores and 128 threads just because that whooshing sound, the shorter I that is the better I'm off. I remember I, this is a long, long time ago, like 97 or eight, I brought you an itanium and wanted you to use that in your home office. And we turned that thing on. And it sounded like an approaching train. There was no whooshing involved. I hope you're a little quieter. Oh, yeah, no, I think that I was actually not even on that itanium. I think it was one of the early dual P4 machines. But yes, no, I cannot I cannot deal with machines where I can hear the fans normally. It turns out now that I've been working with my new machine for a while, when I can hear that it's working hard, that kind of makes me feel good. But normally, it needs to be completely quiet, because that just distracts me. So is there a risk that as you use an ultra high end 64 thread system, that you lose touch to the performance needs of most of the people? Because I feel that the gap between the high end of performance that you're using right now, and the low end of performance that more and more people are using because they are on a mobile device or on a family system. Is there a risk that you become desensitized performance issues? Well, I don't think it's such a big issue for me for the simple reason that I'm not a developer anymore. So I'm not writing the code. The reason I need a big and beefy machine is because I'm merging code from a lot of people. I need to build all of it. But if you actually look at what the end developers do and the end users do, the kernel right now is about 30 million lines of code or something. And then of that 30 million lines of code, in most situations, the only build maybe a couple of million lines that any particular user runs. And also if you are an end developer and you're working on a specific issue or a specific feature, you wouldn't do the kind of builds I do. I build the whole kernel, I build every module, I try to make sure that it all compiles. I only do it for one architecture, which is kind of not what I should be doing, but so far coverage-wise, it's been enough. But I don't think that the fact that I need a fairly beefy machine necessarily reflects very much on other developers or on the users. It is true. I mean, there's no question about the fact that a kernel today needs more resources than a kernel 20 years ago did. My first machine had two megabytes of RAM, and I would never ever run on a two megabyte. I know it works because I've tested it not that long ago. It runs, but there is no way I would use that. Because you were making fun of me for my two megabyte system, but maybe by then you had already upgraded. I was weak slater. Yes, that was weak slater. But yes, so we do need more resources. The good news is hardware has gotten better since in the last 30 years, even if that's slowing down now. Even though we never actually talk about my questions up front, so this indeed is a live conversation, you oddly gave me a beautiful layup for my next question, because you said you're only compiling for one architecture. And with Apple's announcement that they're switching the Macs to ARM, I was wondering if that will change the landscape, the hierarchy of CPUs. Will that actually make ARM64 a true first-class platform as more and more people? I mean, I think it's well known that I actually am usually on a Mac. A lot more people eventually will have Macs, ARM Macs on the desktop. And that's fast forward two or three years, not tomorrow, but in a few years. Well, I've actually been, for the last 10 years or so, I've been complaining about the fact that it's really, really hard to find ARM hardware that is usable for a developer. And I've been waiting for these ARM laptops to come out. I've been fairly disappointed in the ones that I've seen so far. I mean, they exist, but they have certainly not been real competition to x86 so far. I'm actually thinking that the fact that Apple is moving to ARM will help the ARM ecosystem from a development standpoint. The same way that when Apple was using PowerPC, that was the main way that a lot of people do PowerPC development. I used to have a PowerPC for doing Linux development, which was a Power Mac. In fact, I still have a PowerPC, but right now it is not nearly as convenient or powerful as my main machine. So I don't use it. I'm hoping that in a few years, there will be a powerful ARM desktop that can actually be used for development. So far, you can do development in the cloud. There is no question that Amazon with the Graviton 2 has done much better in the ARM ecosystem in cloud than we've seen ARM before. But cloud development is not the kind of development most at least kernel developers want to do. You want to have the machine in front of you. You want to feel like you're eating your own dog food. You don't just want to develop for ARM. You want to actually use ARM in your day-to-day work on the desktop. That's at least my feeling and I refuse to basically develop for anything that I can't use as my desktop. I actually remember a very memorable meeting of you, Andy Grove, Craig Barrett, Paul LaBellini, myself, Pat Gelsinger, where we talked about exactly that. At Intel, this is, oh my gosh, 2002 maybe, where you talked about exactly that, that it is whatever sits on the desk in front of the developer that will win and that Intel's itanium would fail and that it would be x86 that would win. And obviously, you've been right. So I guess we should paraphrase President Trump and should say, Apple, if you're listening, get Linus an early ARM laptop. Is that what we should be doing here? Well, I'm actually more interested in their eventual ARM desktop just because laptops are fine, but I only use them during travel. And right now, I'm clearly not doing any travel. A powerful desktop is what I end up doing almost all of my work on. ARM clearly has been in the situation where their selling point has not been performance. It has been low power. And in that sense, the laptop space kind of seems the more natural but that is also something that I think is changing. That ARM at least has the potential to grow out of the pure low power area. And I think that's where Apple wants to go too. And I'm pretty sure that the iMacs at least, I'm going to have an iMac right here. I believe the iMacs actually are based more or less on laptop boards. So it's very similar architecture wise. So maybe there will be at least desktop style, maybe not super high performance, not at the level of your threadripper, but hopefully a decent desktop machine will come out relatively soon. The other thing as we look at architectural changes that we've seen is that switch to more and more touch-based user interfaces. So I think more and more the people who want to have a keyboard, who want to have an actual laptop are the developers and maybe some content creators. But if I look at our hobby app, I have the dive pictures behind me on subsurface. We see massive growth of users on Android and iOS and not so much growth on the desktop. What are your thoughts about the changes in how people use computers? And as we finally wrap our minds around touch, first generation of voice-based applications are coming out. So do you have any thoughts there on the future? Well, on the kernel side, we really have not had to worry too much about this. The kernel has very few UIs. We have the drivers for all these UIs and we need to have a driver for a touchscreen and the sun has moved again. But we're almost done. But as a kernel developer, I'm largely insulated from these things, except as a pure user of a phone or a tablet. So I have not actually been following it very much. It is clearly the case that as the user interfaces change, the things we need to do in the kernel also very much change. So we have seen a lot of new classes of drivers and it's not just simple things. I mean, a touchscreen is a fairly simple driver in the end. But we're also starting to see all the drivers for AI and completely new things that basically did not exist 10 years ago, just because people's expectations of what a computer does have changed. So in that sense, it affects me as a kernel developer, but it doesn't affect me as in any other capacity. So usually we close our little conversations joking about our next dive trip. I think our next dive trip, if we want to go, is going to be up in Washington State in really cold water. So I may or may not see you there. I may or may not see you there. But thank you so much. I enjoyed chatting with you as always and back to Jim. Thank you, Dirk and Linus. Our next speaker is Heather Miller. She is an assistant professor at the Carnegie Mellon University School of Computer Science Institute for Software Research and founded the Schuyl Center in 2016. Today she is going to share a data-driven portrait of new trends at open source and how we build software. I am very excited to welcome Heather Miller. Hello. Hello from exotic Pittsburgh, Pennsylvania. Very exciting place. Yeah, thanks for the intro, Jim. So as Jim said, I'm going to give you a number of data points today that I've been collecting over the years, just about open source. In general, most often more geared towards how people come together. There's a lot of actual research about this stuff that is maybe just not so prevalent in open source industry channels or events and things like that. So I figured I can give you a tour of some of the things that are both data from industrial firms and then data from a bunch of research papers that point to kind of interesting trends. And as Jim mentioned, I am now at the Carnegie Mellon University. I'm an assistant professor of computer science here. Prior to CMU, I was at EPFL in Switzerland where I did my PhD on the Scala programming language ultimately. I then founded the Scala Center upon graduating and sort of started that and ran it for a few years as the executive director of the Scala Center. So I accidentally fell into a director sort of manager role when I was at the Scala Center. But my real day-to-day is research and in particular, I do research on distributed programming or models for distributed programming and concurrency. And I've been working on these things in Scala for a number of years. And lately we've been getting into sort of trying to ease reasoning about building microservice-based applications and things like that. So that's what I actually work on day-to-day. And we're working on a whole bunch of ultra technical things like redefining the foundation of these replicated data structures known as CRDTs. We just published a paper in the International Conference of Functional Programming this year on that. And then kind of reimagining what fault injection might look like as sort of like a testing thing, as a testing framework. We do all kinds of stuff like this. So the data and the info that I have on open source stuff, if that's my day-to-day, the data that I have about open source is sort of things that I've been collecting over the years, especially when I was this director of the Scala Center. So just to kind of frame where I'm starting with this, it sounds like I'm a person who's just kind of been hacking around on race conditions and weird concurrency bugs. So you might think that I prefer to live in those problems. You know what? I do. I really prefer to live in those problems. But then I became the leader of an open source foundation. And I found this tweet a few years later, which I find amazing. So the two hardest problems in computer science are one, people that I agree with, two, convincing computer scientists that the hardest problem in computer science is people. And three, off by one errors. So I still think that this is true. And since becoming the director of this thing called the Scala Center, I went from doing concurrency stuff and distributed programming and dealing with serialization code and things like that to focusing 200% and suddenly on what's happening in the open source Scala community. And I'd been a part of it for several years while doing my PhD, but it was never my responsibility to try and make anything better until all of a sudden, after I finished my PhD, we're like, okay, we're going to do this. We're going to make an open source foundation for Scala. And our goal was not just to benefit people who are paying into the Scala Center, but it was also just anybody who had an internet connection, they should have a good developer experience that should be for free for them. And when I had to go through this shift, I quickly observed a lot of problems, you know, in the Scala community. And I then noticed that some of these things are problems for other communities as well. And the numbers that I'm collecting for you today are not Scala specific. They're generally open source specific. And then when it comes to sort of industrial statistics and educational statistics, I have to focus on the US, mostly because that's where I am. And also the sort of, you know, a very large developer community is within the US, but some of these trends hold true, especially in Western Europe. So whoops. And so yeah, like I said, I started collecting data on some of these fast changing trends and things that I want to bring to your attention today. So we're going to touch on three topics. Two are maybe something that you hadn't considered. One is maybe adding more data to what you already know. So the one that you already know is that open source is becoming just, you know, the foundation of everything nowadays. Nobby really reaches for proprietary software very much anymore. And I will show you a bunch of numbers that back this up. The other two things that I think that maybe people don't know or aren't as readily aware of is that the way that we build software and what we think a software engineer is, is changing really fast. And it's I, so Dirk and Linus were talking about, you know, the older developers, you know, the 50 somethings, I'm a 30 something. I feel old, you know, you know, just looking at the people coming in and seeing that they have a much different experience than I had. And what I think a software engineer is is very different than what they are introduced to. And I just want to however many years of experience you have as a professional software developer, you know, if you've had more than two or three, you're actually, you know, becoming the minority quickly is my, is sort of my overarching point. We'll see that in some numbers in a moment. And, you know, this kind of hooks up together with how we build software, how that's all changing. So first, people, the way that people are getting into technical careers or sort of software development careers or programming roles is changing very quick. We all know, especially if we're just looking at the US, it's really hard to hire in software engineering. Obviously, we don't, you know, we're always trying to find the best software developers, but you know, there's not even enough software developers for the jobs that we need to fill in the first place. So actually, I'm going to jump quickly to this data point here. So this is actually two, data from two different sources that I superimposed on the same graph. So the blue bars are the number of bachelor's degrees in technical sort of CS or IT related fields given by the US. And these are statistics from the department. There's a Bureau of Educational Statistics and they publish these things, there's a lag of some years, but they publish these things every couple of years. And they, you know, in the last, the last numbers that I have are from the 2015 school year. And that year there was about 60,000 CS or IT related degrees granted by American universities. And from, from that year onward, they had projected about a 7.4% growth. So you could sort of project forward into the future and see sort of how many, how many degrees are expected to be conferred by 2026. And you can see by 2026, we're getting up to 150k. But meanwhile, the, the Department of Labor Statistics is publishing numbers that we're saying in 2017, there were over 500,000 computing related jobs open in the US that were, were, were not filled. So companies were struggling to hire people in 500,000 positions. And what gets worse is that they projected this number is going to get a lot higher in future years. So everybody can be like, Oh, well, what about, you know, tech boot camps, if you don't have a bachelor's degree in computer science, it doesn't mean that you can't be a programmer. It's true. And I am in full support of tech boot camps. I'm a professor and I probably shouldn't be, right? But I think that that's, you know, a great way to start to solve this, this, the shortage that we have of developers. But even if you add that number, those numbers are growing at around the slot, the number isn't on the slide, it should be on the slides that are saved. You can look up these slides, they're saved online in my, in my schedule page, you can download them, look at them yourself, you should see the number on that, on that version of the slides. But the number is about 14%, I believe, you know, rate of increase per year. So, and we're starting to get good numbers about how many people are graduating from these these coding boot camp programs. And even then, you know, we're getting up to just under 200k new developers or people that could be potentially considered entry level in 2026, let's just say. But the Bureau of, or the Department of Labor and Statistics, project that by 2026, that need is going to increase to about 3.5 million. So there's going to be 3.5 million openings. And this actually, so, you know, it's not completely fair to overlay these numbers on top of one another. Because especially that, that huge, that huge number there that the Bureau or the Department of Labor and Statistics, they actually include people coming in, and, you know, people retiring in these numbers. So this is just kind of guessing what the economy would look like. So this is also numbers pre coronavirus pandemic. So perhaps the economy is not going to be as brilliantly, you know, successful or whatever based on the sort of performance of the economy in the last several months. But still the point is that there are a large number of projected openings. And I can't imagine that completely going away. So, you know, if there if this trend continues, it's obvious that there's no way that coding boot camps and US bachelor programs combined can can fill these openings. The Bureau says that about 19% of those jobs could probably be filled by computing degree bachelor recipients. That's it. So clearly this mean Oh, and actually I want to make one more point before I transition out of this is it's that if you so this is these are statistics from the Stack Overflow Developer Survey. These are worldwide. But, you know, what's interesting is that, you know, this this, there is this concentrating over the years of people towards the top in this in these graphs. So what they show is the number of years that people who are filling out the survey, they say a that they are professional software developers and they say, you know, how many years they've been professionally programming. And, you know, there's just a larger number of people concentrating towards the top, which means that people have less than one year of experience or one or two years of experience, most of them less than five. So the point really here is that there is a lot of people coming in. And maybe, you know, I like I said, I'm 30 something, I don't see I mean, I'm a professor, I teach them. But, you know, in any other sort of walk of software engineering, I don't I don't assume that there are people extremely different and with lot less experience than me coming in at a rate that they are. And I think that this is something that more people need to consider. So the TLDR here is basically we have a lot of newcomers and they're they're arriving quickly. And so my point is that, you know, there are a lot of new developers coming in the this this tidal wave of new developers entering our profession is not going to slow down, it's just going to pick up speed. And, you know, the overall like years of experience of practicing software engineers, professional software engineers, that is going down over time, because there are so many new people coming in. And there are a lot of, you know, reasons. Obviously, computer science has become a very cool profession. And there are a lot of initiatives to promote people majoring this in college, but then also people would like to perhaps change career trajectories and get into computer science or programming. And one thing that has sort of enabled some of this growth, as attributed to a man named Caleb Fristo, he's a founder of a coding bootcamp in Tennessee. This comes from the communications of the ACM. It's an article in 2019. It's in the in the slides. So you can go look up this article if you'd like to read more about it. All of my references are at the bottom of the slides. He says that, you know, new frameworks are lowering the barrier to entry. And that's a far cry from the days when you had to learn the syntax of several different programming languages to build useful software. So rather than typing in these seven lines of code to get a menu to pop down, you just download the framework from a code base that allows you to do that in a simpler way. He says, so frameworks are taking the hard work that developers used to pride themselves on out of the equation. So ultimately, you know, the sort of takeaway here is that it's easier to teach people that are beginners, because we have these frameworks that can, you know, do things in in sort of fewer lines of code and fewer sort of like like cognitive cycles, if you will, and, you know, that this is helping. And, you know, another issue that, you know, I would I would be remiss not to bring up is that we have also an issue with existing developers burning out. So what is happening in the face of this this problem where a lot of companies can't fill all the positions that they have, employers are trying to shuffle additional duties onto the employees that they currently have. And so there's a lot of work looking at burnout in software engineering professions based on sort of this having to happen. And, you know, if you ask people related, you know, in the world of hiring and tech positions, people people people at indeed.com who have done a survey on this, they say that this this accelerates staff turnover, the fact that more responsibilities are being put onto people. So also kind of a worthwhile thing to hold on to here. I'm going to make a quick point and plug some research on diversity. So obviously increased diversity would help and also immigration is the US got better immigration. That would be great. And, you know, making it easier to do remote work. These are ways to sort of start to fill this need where, you know, maybe we're having trouble filling it, obviously. And I just want to mention I'm going to just mention some research that I would encourage you if you're interested in any of this to have a quick look at when you have some time. Basically, there is research that says, and this is from a colleague of mine at CMU, his name is Bogdan Vasilescu, that, you know, if you look at the productivity of software engineering teams, and this is looking at teams on GitHub over a long period of time, if you hold other confounds fixed, teams that are more diverse with respect to both gender and tenure, tend to experience or sorry, tend to write code a lot faster than teams that are less diverse in these ways. And so, so, you know, what that means, actually, you know, this is another point I'm just going to show you it's in the paper, you should look at this. There's another paper about how, how particularly women lose engagement faster. And, you know, this idea of having this, you know, mixed sort of diversity in terms of gender and diversity in terms of experience, it tends to lead to people building develop building software, better software faster. And ultimately, this is basically, you know, there being diversity, people being sensitive to one another. And there are being people with different skill sets from very experienced to very inexperienced on the same team. So people end up kind of feeling more comfortable sharing, you know, what they do when they do not know people are more safe to just kind of learn from one another. And that's kind of, you know, a very unscientific interpretation of all of this. But okay, let's get back to you the rest of the points that I wanted to make. So I mentioned that the way that we build software is changing. And I think that a lot of people have, so I'm not going to spend a lot of time on these open source surveys by various companies, because I think a lot of people know these already, but I'm just going to quickly summarize them. So Black Duck has been doing this future of open source survey. They're now synopsis. And, you know, over the years, you know, from 2010 to 2015 in particular, they noted that out of around 1200 companies that they've been surveying, the increase in the reliance on open source software has doubled. That's of as of 2015. Obviously, that number keeps on increasing, right? So in 2015, companies only would consider 66 or two thirds of companies would consider open source options before proprietary alternatives. And that was that was already a few years ago, right? So by then, open source is becoming the default choice. People would need to consider proprietary choices. By 2017, in the in these, these Black Duck slash synopsis surveys, companies said that they increased their open source usage. And the main reason that they, they claimed for that was that it was lower costs and there was no vendor locked in. And by 2000, I think 18. So this is now, you know, scanning dependencies of commercial code bases. Open source components were found. So out of 1100 code bases scanned, open source components were found in 96% of applications that were scanned. And there was an average of 257 open source components per application. So 96% of companies were using open source in 2018. And, you know, the average number of open source components that each company was using was a whopping 257 components. In 2017, then the percentage of a code bit of these company code bases that were considered open source components was 36%. By 2018, that number had increased to 57%. Okay, so it's, it's, it's a shocking change. There's a company called HideLip that maybe many of you have heard of, they've, they've observed similar things. And that is that open source applications are 70%. I'm sorry. Most applications that they are scanning and analyzing, which are, you know, closed source or end user applications, 70% of them are composed of open source components. 20% is custom application code or business logic and 10% is sort of infrastructure. So Linux or Kubernetes. So basically 20% of what, you know, your engineers at your company are writing, you're only writing 20% of the application, which is amazing, right? That, that we're writing not all of it by ourselves anymore, finally reuse works. So yes, take a second to internalize that in 2018, 70% of code bases were open source components, according to TideLift and in 2018, 57% of code bases were open source components. So that's still a majority. It's amazing. So I'm going to jump over this point, but I love these quotes. If you're interested, so Mike Krieger, who was a co-founder of Instagram, basically argued for reusing overbuilding yourself. And, you know, at the same time, so like, yes, let's do that. Let's build our startups on this. Let's become unicorns. But according to TideLift, who continues to do a number of these surveys amongst open source developers, they say that around 62% of respondents, you know, they have to financially support themselves or do all this on the work, all this work on the weekends or that there's not a company backing them. So that's incredible. That's a huge number. So I'm going to mention a few things that are a little terrifying that we might already know about. So we know about Heartbleed and sort of the TLDR about things like Heartbleed is that, you know, you have two thirds of the internet using OpenSSL and then you've got everybody jumping on this bandwagon and nobody realizes that OpenSSL at the time before a bunch of companies started investing money in it, OpenSSL wasn't even able to support a single person's work, even though two thirds of the internet was using it. So those are things that hopefully the Linux Foundation is here to fix. Then we have things like the truck factor. There's researchers actually trying to measure things like the truck factor. So the truck factor is the minimal number of developers that have to be hit by a truck or quit or be otherwise incapacitated or sorry, be otherwise, you know, disappear from a project for the project to become incapacitated. So Linux is awesome. Linux is a super high truck factor, but there's a lot of other things that are pretty widely used that have very low truck factors, things like Netty and Clojure and Cassandra. A lot of people use these things and they don't realize the truck factor is rather low. And if I've learned anything from the Scala community, it is that ecosystem and community is really everything because we have had a lot of issues with community in the Scala ecosystem. And just to throw another paper in here in case you're interested in reading about it, this is how programming, this is some numbers about programming language adoption. Really, the thing that I'd like to point out here is that if you look at the top of this graph, so basically these researchers did a lot of surveys, they analyzed a lot of code bases and they found from talking to developers and were talking thousands and thousands of developers, up to 13,000 developers, that the main things that were important to developers when deciding whether to adopt something in particular programming language, it was that there were open source libraries, they could extend existing code in that there was some familiarity with it. So these are all extrinsic factors and not intrinsic to the language, not like, oh, this has type for it doesn't have types. Really what was more important was actually the open source libraries and the open source communities. And Tidelift, oops, Tidelift, oops, the thing is over the text, but Tidelift has found the same thing. Ultimately what they found was that professional users, people who want to adopt open source libraries, they want an active community. And so the most important thing, according to Tidelift, was that software is reliable and well maintained, it has an active community supporting and using it. And that software maintainers provide timely bug fixes, they have the resources and abilities to do that. So, oh my god, I gave you too many things and you're probably all dying. The main sort of point here is that there's research that points to the fact that community and ecosystem are among the most important factors to an open source project, to an open source project success. And that's it. So I just want to provide a couple of sentences of summary and then I will let you all escape. Basically, the takeaways from this talk are that the way that we build software is different than it was when Linus decided that Linux was a good idea. People are just building on top of frameworks way more than they ever were. So it's becoming easier to teach newcomers things. So this whole point of developers used to pride themselves on very efficiently ways to implement something. Now we just tell newcomer grab that thing off of a shelf and reuse that thing off of a shelf. That's how it's going. We know that there are sustainability issues in open source, things like the Linux foundation are hopefully helping that, but still sustainability issues remain. And then finally our idea of software engineers is also changing. So we have this huge influx of newcomers and we need those newcomers to fill some of the holes that we inevitably are going to have in the future. So this means looking at ourselves and trying to develop cultures of mentorship and looking at some of the scientific research, if you have diverse teams and you have a diversity and experience, you can actually expect that they will develop code faster than teams that are more homogeneous, according to the research. And I'm really happy to talk about any more of these things. I will be in the Slack channel and I can, I think, end it here. I'm not sure if Jim or somebody's going to come back on, but I will go to Slack and I'm happy to answer questions or talk more there. And also the slides are posted on the schedule page. All right. Thank you, Heather, that was really good. And to directly answer your question, the Linux foundation definitely wants to help with projects. Open SSL is one that we have written grants to. We're also working through our core infrastructure initiative and Harvard University's lab for innovation science to go do research on the intersection of projects that are critical to the collective society and internet and really need help and sustainability. We also have fundraising programs through our community bridge platform to help raise funds for maintainers who maintain these critical projects, free security tools for those folks, and sneak preview. We will be announcing a new initiative to help with the very issue that you talked about. I also love your point on the need for more diversity in our communities. We believe in that as well. As I mentioned today, we are announcing 500 training scholarships for people who either can't afford them or are from diverse backgrounds to bring into our community and train them how to be better developers. We have a mentoring program maintained by Shua Khan, a Linux kernel developer. She is matchmaking mentors and mentees to bring a diverse community of people into our world. So that and many, many, many more things will continue to do it. We completely agree with it. I loved your talk. Thank you so much for being here. Thank you guys for having me. I appreciate it and I'm sorry I inundated you with numbers. No, no, no. We love the numbers and let's share our notes. We have a second phase of our research going on and we love to give you access to that data set as well. Got a new paper for you, by the way. I should probably pass it to you. So send it over. I'd love to see it. All right. All right. With that, we have a few final announcements from sponsors. Creditive is announcing their post-sequel enterprise package today. CircleCI is announcing a new suite of open source integrations developers can use to automate and streamline browser and mobile testing. White source has released research which assesses software vulnerability prioritization based on insights from hacker forums including the dark web and deep web. Please visit the sponsor info channel and Slack to receive more details on these announcements. Also, check out our sponsor showcase. Talk to other attendees in our Slack workspace and do not miss conference sessions starting at 1130 central time. Thank you everyone for bearing with us during this first of our virtual large virtual event series. Hopefully we'll have many more to come. Thank you all very much.