 I hope you enjoyed the conference yesterday and thank you so much everyone for joining us. Today is the keynote. We have an exciting lineup today as well, being with our first speaker, Corey Hohlen, CTO and co-founder of MatterMOS Inc. MatterMOS is the creator of open source enterprise messaging workplace, good for privacy conscious organizations. Prior to MatterMOS, Corey founded TEPCO AI, a machine intelligence startup spun out from Stanford Research Institute, which was acquired by Salesforce.com. Today, Corey joined us to discuss working effectively in remote environments. Please welcome Corey Hohlen. Hello, my name is Corey Hohlen. I'm co-founder and CTO of MatterMOS and I'm gonna be giving a talk about working effectively in remote environments. So a little history or story real quick. MatterMOS is a fully remote company. We've been fully remote since our inception. So we've been operating in this sort of environment for the last five or six years. So let's, before we can really talk about the effective work, maybe we should talk about some of the sort of benefits and drawbacks. So what are the benefits of fully remote development? Some of the benefits that we find are, you have that sort of quality deep work time, that quality time where you're just, you have a lot of focus time where you can work, you can do it out you set to achieve, you don't have a whole lot of external interruptions. And we find that's probably one of its biggest advantages. The other advantage is sort of that asynchronous nature, you have less interruptions, you have less people coming by your office or your cubicle or less distractions out there as well. So just the ability to really focus and that asynchronous ability which causes a lot less interruptions. We as a company also find this to be advantage because there's a vast sea of resources out there in terms of people who wanna work for remote style companies. I know in the age of COVID and we'll kind of talk about the differences that we see. I mean, that may change for the future and I think that would be awesome if it does happen. I think remote work is definitely a benefit for all. The other big benefit is it saves things like commute time or drive time. So you have even more hours to spend with your family or do other stuff or whatever it is, more focused time. So we find that as a company, having that ability to have access to a lot of that vast sea of resources is really important. And then what it ends up attracting is people who are sort of very mission driven, right? Most sort of fundamentally believe in the work that they're doing. I always kind of break it down into to be successful in a remote environment. We'll kind of get into these two things but you have to be, there's kind of two things. One is you have to be really good at asynchronous written form communication. We'll talk about that. That's one. And then two is you have to be internally motivated, right? There's no external peer pressure. There's no peers sitting next to you. There's no external boss hovering over you, right? So what we find is we fundamentally find people that sort of believe in this work, believe in the nature of what we're doing. The other interesting benefit, pre-COVID at least was you could be a digital nomad. I was kind of the poster child for that for a number of years. So I spent two summers in Alaska and two winters in Florida and kind of everywhere else in between. So as long as you have a good internet connection, you could work from anywhere, being a knowledge worker in a remote environment. So I know those may not be familiar with American geography or whatever, but Alaskan, Florida, about as far apart as you can get and still drive a car in between them. So it's, I don't know what it is, probably 3, 4,000 miles apart, several thousand kilometers. So, and I kind of spent everywhere in between. And so it's being remote is one of those lifestyles that you could have. And it gives you a lot of, I think, at least sort of mental health, right? If you're often doing a bunch of different fun stuff. Those are actually pictures of me kind of sort of all over. We have what we call MatterMug. So it's a mug that we give to our community members or participate in MatterMug's open source project. And I just like to take pictures with it in strange locations. So what are some of the drawbacks of being full remote? I mean, they're definitely in our drawbacks. I'd say that probably one of the biggest ones is what I like to call virtual doors, knocking on virtual doors. It's really hard to do. Like if you think of yourself being in an office, in a physical office, and somebody has a shut door, it's really hard in that physical office to go knock on that door, interrupt somebody, say, hey, I wanna spend some time, let's talk about X, Y, and Z. It's even harder when you talk about a virtual door, right? And so that's one of those things that we try really hard with certain tools and techniques to sort of get past, but it's definitely a drawback, right? The other one that's sort of, one of those ones you don't really think about is who's in the office, right? It's really easy to see when you show up to a physical office, who's in and who's not. And you get a sense right away that, whether you go to lunch or whether you do stuff like, oh, Joe or Sally must be out on vacation because they're not here this week or whatever. So it's one of those things that you kind of miss when you go to a fully remote environment. It's just that really easy way to detect who's in and who's out. And lastly, one of the biggest drawbacks, I would say is everything kind of turns into the disneed for a scheduled meeting. When you're remote. And that's something that we try really hard to defend against, but we understand that it's part of the process, it's part of being remote, but you do have this sort of, everything kind of turns into this scheduled meeting, need or whatever. The other big drawback, especially in this time of COVID is just that sort of missing, human face-to-face time. We as a company, like I said, we were remote. We've been remote since our inception. We as a company have always struggled with this, right? And I would say more so now post COVID and we can get into the reasons why, but we at the very least as a company, and here's some pictures from our previous, what we call MatterCons, we at the very least as a company and a community, open source community, we used to get together at least once a year at MatterCon. So we would actually fly in all of our staff members, fly in a bunch of our community members and just have a big meetup at least once a year. The feature teams would actually get together more than once a year. Some of the feature teams got together several times a year. And it's just a great way to sort of build trust, to sort of get rid of that human element, to see people face-to-face. Like there is some, you do have to recognize there is some need for that. And even for us, right? During COVID, we kind of shut down all of our meetups and stuff like that. So that's even been challenging for us, right? So we do a lot of other kind of activities. And it's not the same, it's a good sort of supplement. But even we recognize that this is one of those things that were, at least I'm hoping, after COVID that we can get back to doing. Cause there really is that need for that human face-to-face time. So we kind of talk about benefits and drawbacks. Let's really quickly talk about what does effective communication look like, especially when you're remote. You know, good communication. You need to be an organization that values asynchronous communication or an open source community. We're actually both. We're a company and we're also an open source community. So you need to be really good at that sort of asynchronous written form of communication about writing everything down. So we strive really hard as an open source community and as a company to really be open and to be open to writing everything down, especially for us, because we deal with people all over the world in all time zones because of our open source nature. And so the only way that you can always get sort of, you know, conceptually everybody in the same room is by taking a copious amount of notes and writing those notes down in some sort of, you know, persistent chat system. We're also really good at ephemeral video. It's one of those things that we recognize, you know, video is a great form of communication. We'll kind of go into that in a little bit. But, you know, being really good at sort of dropping into ephemeral video, taking notes and dropping back out. You need to write everything down. I kind of already talked about that. You need to be anti-meeting. This is hard. Like, we struggle with this as a community and a company. But we're very conscious about when we're adding meetings. We try really hard to go through and remove meetings. I mean, you're definitely gonna have meetings. It's, you know, that's just the name of the game. But you have to remember that in the remote world, you know, everything kind of needs to be scheduled, right? Everything needs to have a meeting start time, end time, and there's not this serendipitous sort of meeting together. But it's, you know, you just need to be sort of aware and try to limit those types of, try to be very understanding and limiting in terms of what meetings you're adding. The last is simulated water cooler time. So this is probably the only questions that comes up the most. Like, ah, Corey, like, how do you guys do brainstorming? We do do brainstorming. We have very much sort of that ad hoc hang out together time. And the difference is it's just the scheduling of it is just forced like the event itself is very serendipitous. We talk about a lot of different stuff. We do it a lot of different ways here at Mattermost. Most of these ways we always invite the community. So we sit together with the community and the company together and we do these different things. They range, they go all the way from things like tech moonshots where we kind of just sit around and discuss what we think we'd like to do, you know, architecturally and for the future all the way down to things like dev hangouts. So we have a weekly audio only chat where people can go into the hangout. They can just hang out, chat, talk about tech, program while you're sitting there. Listen, other people talk about tech. It's just a great way to build connection. So I would say like, we still have those serendipitous water cooler meetings but they're very scheduled or structured, right? And the other example is, you know, people talk about what about brainstorming in the office and I'm like, yeah, we do the exact same thing. We schedule brainstorming sessions and we just have, I'd say the big difference is ours is probably more effective. It's a little weird to get set up and it's a little weird to get used to but I would say ours are a lot more effective because we're really, once we remember, because of our environment, we're really good at being asynchronous communicators and really good at taking notes. So the classic example is if you're in a, you know, if you're in the building and you're having a brainstorming session, you go into an office, everyone whites on a whiteboard and that whiteboard is a free flow of ideas. It's some stuff over here, it's some stuff over there, it's some stuff over there and use the outcome of that, at least in my previous life, as you go there with your camera on your phone, you take a picture of it, you send it to everybody, you know, over email or whatever and that's how you document the event and when you think about it, when you think about it, that's a really poor way to do it. So what we're really good about is creating something like a document that goes along with that session where we're kind of keeping track and somebody's, you know, taking copious notes and so you end up at the end of that session with a really amazing sort of brainstorming document. So next, let's talk about, you know, what tools should I use for effective communication in a remote environment? And we'll kind of go through some of these different tools. I think first and foremost, the most overlooked one is just the home office setup. You know, you need to be, and especially I think, you know, because of things like COVID, people, you know, you just sort of went to the office one day and the next day you started working from home and that can be really hard if you don't have the right setup, right? And whatever that setup is for you, like, so if you're a company with staff members, you know, we really encourage you to make sure your staff are set up correctly. They have whatever it is that they need, the right video, the webcam quarter or sorry, webcam, the right, you know, headset, office chair, desk, whatever it is, like invest a little bit in that and getting that set up for your staff members. Of course, you know, I'm biased, so the next is having a channel-based collaboration sort of persistent chat. I think that's probably one of the biggest ones in terms of this remote sort of collaboration and being effective. Once again, I'm super biased, like, you know, found a MatterMOS on this premise of like, I think channel-based or top-of-base communication is really important. That's what MatterMOS does. So if you're not familiar with MatterMOS, it's a, you know, it's an open-source alternative to Slack is probably the best way to describe it. And at MatterMOS, we use MatterMOS. We use it, you know, hourly, daily. We run our entire company and we run our entire community. So we have a community server that has 9,000 plus community members on it. I think we're getting close to 10,000 now. Several hundred staff members sit there and that is how we run our open-source project and that is how we run our community. And it kind of boils down to like one very simple thing, like channel-based or topic-based chat. So that's kind of important. That needs to be persisted, needs to be have history, it needs to be channel-based or topic-based. I truly believe, you know, when you think about things like channel-based, I truly believe something like email is the best for external communication, communicating outside of your company. But chat or channel-based is the best for internal communication. And it's for a few very simple key reasons, but email is inherently private in the sense that that information is siloed in my inbox, in my email. So that's kind of one big strike against it. It's just that private nature of email. When you're talking about wanting to be collaborative within, let's say, a company or a community. And channel-based or topic-based chat is very open, right? If you have access to the channel, you have access to all of that shared knowledge and anybody can be added to a channel in the middle of it and get access to all that shared knowledge. So that ability to search that history is really amazing. And you have that async nature, right? That ability to go asynchronous. Chat is really interesting because it's one of the few tools you can actually do both. And we do do both. When we're talking about channels or thing publicly or interacting with the community members that we know sit in very different time zones, we have a very asynchronous mindset, right? We're gonna send somebody a message and we know they're not gonna get it till tomorrow and we're not expecting a response. One of the cool things about persistent chat though is you can drop into this synchronous mode, right? Where you're having, let's say, a direct message conversation with somebody and you're just literally chatting back and forth in real time. So it really gives you that advantage as well. And lastly, what I'd like to say is sort of, we call it integrations and bots for central command, however you wanna describe it, but it's the ability to take structured data. So this is data coming from things like integrations and analytic tools and let's say logging tools, whatever it is. Piping structured information into a channel and then having unstructured information or information coming from humans augmenting that information in a channel. So the best is talk about an example, right? When you talk, let's say, incident response. You're having an outage at your company or whatever service is going down. There's no better way to act, especially as a non-remote company, but especially as a remote company where you're kinda getting everything in the right sort of topic at the right time. So you're getting automated stuff pumping messages into that room where humans are sort of doing the analysis and investigating what's going on with the outage and having people respond there in real time and being able to hand off that event. Like, hey, it's my nighttime. I'm ready to sign out at someone else's on-call schedule. Just gonna come over and take over this event and they can automatically join the channel and see all of that stream of confidence, that shared history, that shared command line. That is a super powerful concept when you're talking about sort of channel-based collaboration. So, like I said, I'm biased, coming from outermost, but we believe channel-based or topic-based communication is one of the keys to running a sort of fully remote team. The second most important pillar in sort of remote collaboration is ephemeral video. I think it's one of the things you have to really be good at. I mean, I know people in the time of COVID, people have already gone to it and they're holding meetings there and stuff like that, but I think there's a few key differences. Of course, when you're having meetings, you're having ephemeral video. When you're having one-on-ones, you're doing it through video. So, video has a lot of implications, especially ephemeral video, that make communication really easy. And we have a lot of ephemeral video. The key, once again, is being very good at taking copious notes and taking those notes and posting them back into a channel, especially when you're having a sort of brainstorming session or whatever it is. So, let me just grab a scenario to you where we're really good as a community and company in the sense of, you can see those conversations in a manner most evolving, right? There's some conversation that's, 50 replies deep on this thread, and you can tell people are communicating on that thread and they're just sort of, they're kind of talking past each other. People aren't understanding each other's point of view. And you'll see, you'll see in our community it's really interesting, you'll see someone like, hey, let's just hop on a call. Like, all right, and so they'll go over to a Jitsie video or something like that and they'll sit in that Jitsie video for, they'll bring up that ephemeral video and they'll talk. The reason they do that is because pictures worth a thousand words, right? It's a lot more efficient to communicate. It's a lot more efficient to understand people's opinions or sides of the argument. And there's the little nuances that you get in video, right? Which is really important. It's key to sort of that human interaction, which is you can, it's easier to tell when somebody, the written form of the word versus the spoken form of the word, it can be really hard to tell when somebody's joking, or someone said that in Jast or, so it can be really hard to pick those things up sometimes, but it's really easy when you talk about it, or a lot easier at least when you talk about it in terms of seeing somebody's expression and how they're responding and seeing either, like, oh, that person's totally relaxed and joking. I thought they were upset. And that's one of those things that comes across a lot easier in video. So you'll see lots of times the conversation in chat will devolve, the group will immediately join a video, they'll hash it out. And the key here is while they're hashing it out, they're taking copious notes and they'll post that information back into the channel. Here's the outcome, right? Because one of the things that you realize, especially as an open source community, but as a company that goes fully remote now, it's a lot harder in the sense that, there's always gonna be somebody out, there's always gonna be somebody, whatever, is it sick or on vacation, or in our case, an open source community member who might be asleep in the middle of the night, right? And you wanna share within the details of the outcome of that conversation. There's nothing more frustrating than seeing a conversation, seeing it got moved into some video chat and then there's no summary of it posted back in the channel, like, well, wait a minute, there was some important discuss there, what was the outcome, right? And you want that asynchronous nature. And then that's really kind of key to this ephemeral video piece. It's sort of being able to drop into those conversations, take copious notes, and then post it back in the channel. Next, we'll talk about shared documents. So I think this is sort of the last and third major pillar, I would say. You really need a ability to share documents. So whether this be something like an open source one, like Klabra Online, or something like Google Docs, you really need a document system that kind of captures that structure. And you'll see us do this all the time in Matterma. So we're really good at using persistent chat for things like async, even things like sync conversations are really good for using ephemeral video for discussing stuff. And we're really good at using sort of documents, shared documents for things like capturing structure and long-lived documents. And they're kind of, it's very subtle in terms of when you think about when you use each of these tools, but it's very meaningful and impactful in terms of how you do it. And you really want that long-lived document. You really want that document that gives you some really good structure that you can go back to or you can share outside of, let's say, your channel or video that you're working on. And so just having, and like I said, this one's, you know, it's one of those ones kind of obvious. Like, wow, Cory, everyone uses some sort of shared document. Yeah, they do, but they don't necessarily create a shared document for everything, right? So, and I'm not suggesting that, but I'm suggesting like create more shared documents than you think, right? So the best example is, we create shared documents for even meetings. So we have a shared document where we run our weekly recurring R&D meeting and we just go in there and put the agenda in there. People can go and put comments. People can come in and say like, hey, I want a demo this week. And then we have like a running history in that shared document of what happened in a very structured way, right? And so that's just kind of one small way. And so, you know, most people use documents for things like, you know, producing, let's say, SPACs or design docs. Like, yes, definitely use shared documents in that, and we do too. And those are still great, linking those in the channels and stuff like that. But we also use a lot of shared docs for, like I said, things like meetings, specific meetings. We also use a lot of shared docs for things like one-on-one, right? One-on-ones with your manager, right? So you can go in and you have this running shared doc of one-on-one stuff that you can both add to. And like I said, it's, maybe it's an obvious thing, but it's one of those things that's not so obvious in terms of, you know, using that kind of tool more because that structured document, that long-lived document, gives you something different from, you know, persistent JAG, gives you something different from a FIMO video. Yeah, so how can you reach? Thank you. How can you reach me? The best way to reach me is probably on our community server, community.mattermost.com. You can just add message me at Corey. You can always use email, Corey at Huland, or my personal email. Sorry, my work email, Corey at Mattermost, or my personal email, Corey at Huland.com, or on Twitter. So that's the best way to reach me. But I would love to hear from you. I would love to hear, what are some of the things that you struggle with? What are some of the things that you, because like I said, we don't have, I know, you know, we don't have all the answers to all this. Like we constantly trying to, we've been doing this for five, six years now, and we're constantly trying to improve. So if you could share with me your thoughts and processes and experiences, like I would, that would be awesome. So please feel free. And thank you very much. Thank you, Corey. Our next keynote speaker is Adam Kibbit. Adam works on Connected Vehicle and Project Engineering at Canoe, a company that is innovating on the idea of what it means to have an electric vehicle in the city. Today, Adam will discuss the symbiotic innovation of using open source at startups. Please welcome Adam Kibbit. Good morning. Good evening. Since this is a virtual conference, I'm not quite sure what time it is for everybody, but welcome. Today I'll be going through a symbiotic innovation open source for startups. Just to kind of set the tone for the discussion, give a quote from Guy Kawasaki, ideas are easy, implementation is hard. I think this quote really captures the problem statement and some of the troubles that steps tend to go through. In terms of the agenda, I'll give a quick introduction of myself and Canoe. We'll talk about what makes a startup hard. What are some of the problems that a startup has to go through on a daily basis? We'll dive into those problems and discuss what open source software helps, provides to help solve those problems. Then we'll talk about what startups do to provide, to provide back to the open source projects or open source software to create that cycle of symbiotic innovation. And then we'll give some final thoughts and conclusions and what are the next steps and where do we go from here? Introductions, my name is Adam Kibbit. I've worked in the automotive industry for about 15 years, working on electronics and software. I have extensive experience in infotainment, connected vehicles, cloud services. And I've worked on everything from 16 bit micros to complex cloud systems. I work at Canoe. I am in charge of the connected vehicle and digital product engineering groups. And Canoe is an EV company that launched in 2018. We reached beta in 19 months. And along the way, we've developed this highly modular skateboard platform containing all the components of electronic powertrain. And the areas where I work in the connected vehicle area, we have used open source projects and automotive grade Linux to create our unique user experience. So what makes a startup hard? Well, the first challenge to talk about is crazy timelines. Speed to market is often a big thing for startups trying to hit a window of viability for a product or trying to get things out before a competitor gets their product on the market is usually very critical for a startup. In addition, going through product iterations and proof of concepts and really kind of going through this to resolve the product goals, to understand precisely to refine that product into something that is saleable and useful. Proof of concepts help to kind of settle these differences and provide feedback to this process. And they also are very useful for providing demonstrations to potential investors or customers. The next challenge is financial management. Every startup has to be cost-conscious. They don't always have an income source. They're kind of on a limited budget and so to understanding precisely what you're getting before committing to it. So you tend to try a lot of things before committing resources or committing funds to something. And understanding when to spend the money. So when exactly do you need to spend the money? Not always you need to spend everything at the beginning of the program, but obviously after too late in the program can be a problem. So understanding exactly when to spend the money is important. And then knowing the full cost of commercialization, how much will it take for you to create, to take the proof of concept or the product that you have currently and put that into production. And so those are some of the challenges. In addition, startups tend to run skeleton crews. They tend to have very, very small teams. And the teams are kept small for a reason. It's a lot easier to keep a small team aligned and focused on a singular goal. As teams grow, communication and processes become necessary and they start stifling innovation and start stifling the productivity of some of its higher performing members. And so to kind of control this, you have to understand when you need people to be added to the program. You need to find flexible team members and really understand the needs, the skill sets that you're looking for at that given time. So how does open source software help to solve these? Well, for crazy timelines, open source software provides a starting point. It provides foundational components and other building blocks that are useful for getting off the ground. Sometimes just getting started is the hardest part of a project, especially when you're given a blank sheet of paper, which is precisely the situation we had here at Canoe. And so just getting that little kick in the rear to get going is an important aspect of open source software. And open source projects like Automative Grade Linux provide a great set of foundational components to enable this type of building. To kind of build on that, open source projects often provide reference designs and implementation. So you can take and create a sample application fairly quickly with many open source projects. And so this helps to spur the designs and also helps to quickly build up proof of concepts. And as mentioned previously, proof of concepts are key to the design iterations and providing direct feedback to the product definition process. And Automative Grade Linux is another, it also provides a lot of resources here too to allow you to quickly build and install software and get things up and running and provide demonstration and reference platforms that can allow you to create those really neat proof of concepts that are useful going forward. And all of this, you kind of combine all of this and it really provides a shorter path to a demonstrable product. It allows, it creates things that people can interact with and creating real software and providing real interactions is always preferable over PowerPoints are great and they definitely serve a purpose, but if you have something to show a demonstration or real product interactions are always a preferred method. And it really gives you the opportunity to test out your theories to understand what's good and bad about your, about the product that you're developing. And so to kind of continue on this, if we look at financial management, so what is open source software provide from a financial management perspective? Well, the initial investment is fairly low. The, it's, when the difference, going for commercial software versus open source software, when you're going in front of a budget meeting or sourcing council to get resources to pay for project fees or license fees or you need this fee to get started fees, it's often difficult to explain to people that I just need this right now just to get going. It doesn't really give us any working software. It just gives us the ability to develop on this. That, that always often creates, creates some interesting conversations. And so if you have the option to go with an open source project where the, the, the software is at, you know, at no cost or, or, you know, and provide you, provide you similar, the similar ability to get started. This is often, often much more preferred. And then maintenance. Maintenance is one of those things that often gets put on the column of, it's a, it's a negative. But I, I see maintenance as a, as a positive. Maintenance, it can be, can be kind of scary because you don't, you're, you're picking up an open source project where there's no support that they're, they're, they may not, they may not be a support system in place. And, and so you're, you're taking on a lot of responsibility and a lot of risks and a lot, and, and so it can be quite intimidating at the, at the beyond side. But the control that open source projects give you allows the startup to really become a master of their own destiny. By working with and understanding the open source project rather than fighting it. The, the skills within your organization will grow. These skills will, will then become an asset of the organization and allow you to insource and reduce outside dependencies, making forecasting of, of like future support and maintenance costs more straightforward because they're not dependent on, on what another company will provide. It's all, it's all based on what your, what your capabilities are on within the company. And then the last, the last aspect of financial management is obviously it is, is cost. The license and royalties that you, you pay often get attached to the product, final product costs. And while these vendors deserve to, to ask for products that they've put in, put in hard work to create, not having these, especially for a startup allows you, provides you significant flexibility to provide your products, your end products at a, at lower cost to your customers. And it is really, it can be, it can be seen as a way of giving back and putting all of this together, it really, you know, kind of ties, that ties, ties a nice bow around, you know the path to commercialization. You, you have, you understand what it's going to take to maintain. You understand what the costs are going in and you understand what the initial investment is. And so this makes it much easier to, to realize to realize a production or commercialization path. And so the last one for, for team size, open source provides a community. There's always a word that you'll worry that with open source you'll be, you'll be on your own. But I've kind of found the opposite. Forums, mailing lists, IRC, IRC channels, all of these provide an avenue, a support channel to, to, to get, to, to ask questions and get some feedback. And so while, you know, some, some people think, you know, it's, you, you're going to have to solve all these problems on your own. You won't have any support. I, you know, I've never felt like I was alone. There always seems to be a, a like-minded person out there who's trying to solve a similar problem who's more than happy to have, to provide a helping hand or even just, to just kind of talk through potential solutions. And then technical documentation. Technical, technical documentation is always, it was always seemed, always seemed to be a selling point of commercial software. But now the communities behind open source have made it so commonplace to see good, if not great documentation associated with each, each project. It has really reduced the intimidation factor that comes with taking, taking on software that you don't know. And it makes, makes the integration of these projects so much easier. The fact that you can see how the software works, you can understand, you can understand how, like, how it's intended to be used. And you can, you can read what are the, what's the error cases and, and fail safe scenarios. It makes, makes the, the maturity of the application that goes on top significantly better. And then the last, the last aspect of this is, is a larger community really means there's more people out there in, in the case where you actually do want to hire people. No longer do you have to, to find people with a, like an archaic or a very specific skill set, skill set or technology set. You, or, or hope that they'll be able to come in and pick up your proprietary architecture. You can rely on some open, open and standardized skills. And it generally makes, makes finding people that can help your, help your company out significantly easier. And as I mentioned, like finding, finding the right skill set at the right time is important for a startup. And so what do startups provide in return? I talked about all the things that, that startups get out of this relationship. What do startups provide in return is startups can do things that, that larger companies maybe can't. And so they, they can push boundaries. They can push technology boundaries, user, user experience boundaries, product boundaries. And, and so what do I mean there? The technology boundaries, if you look at all of the AI autonomous startups that are trying to push the, the boundaries of what's possible on autonomous, autonomous vehicles. A lot of these, a lot of these companies, a lot of these startups are using open source projects. And so by using the open source project, the open source projects get more, get, get associated with it, with the successes of that startup and more people are encouraged to use those, there's open source projects because of it. Startups can also push the user experience boundaries by, by putting a different spin on the same problem. Startups can, can, can change, change the conversation around, around user experience. This is an area where I think Canoe has, has, has, can have some impact as we're, you know, we're taking a different spin on, on our user experience. And by using automotive grade Linux to power our experience, it shows, it provides an alternative example or alternative use case to an already impressive open source project. And then finally, it starts can push, can push product boundaries. Tesla is a great example of this. They've pushed, pushed boundaries on what, on, on what the product can do from, from, from EVs and traditional automotive. And, and, and their Tesla's reliance on Linux and open source technologies, kind of furthers that conversation and shows that it's really possible. And then the startups can also contribute to the community. And this may be a little bit, the, the benefits here, you know, are a little bit more obvious, you know, with startups being able to, to find bugs and commit patches, commit fixes and patches. You know, as, as, as more people use it, it's obvious that more people, more, more developers will be able to have a look at it and kind of create new features and even create new projects. You know, the canoe has plans to, to, to contribute back to the open source community as well. You know, as our, as our company grows. And then the last, the last thing that startups can provide in return is startups can be open source advocates. And a great example of this is what I'm doing right now, presenting at an open source conference, being vocal supporters of open source and the, the projects that are around it and provide, provide great examples of what's, what is really possible with open source. And so some final thoughts. So, you know, kind of when I look at this, I look at, I look at how startups and open source really are made for each other. They really need each other. They, startups, startups definitely get, get some benefits out of this. They get a head start by using open source technology to kind of jumpstart their product, product development and, and, and engineering efforts. Open source, open source software open source projects also get benefits out of this association from, from kind of latching onto the successes of startups to, to being, being accompanying the technology and innovation changes that, that, that surround them. And, and, and when you really, when you start putting these things together, you can see how they, it's this snowball effect of a symbiotic innovation to where both, both startups and open source projects can really, can really create amazing things together. And, and that, that, that innovation, that symbiotic innovation that's created from these, from this relationship is really something we all need. Startups powered by open source can have the ability to create amazing products, amazing services and amazing tools that not only create great user, great experiences for, for users, but also spur innovation. They, this, by, by changing the, changing the conversation on, on new products and new ideas, whether they're successful or not, by, by just changing, changing the thoughts of those around, it helps generate those new conversations and, and, and those conversations really have an effect on, on innovation, creating, creating real innovation around, you know, as, as things that were deemed, maybe not possible or not likely, all of a sudden become, become a real possibility and, and open source has been essential to canoe success. And it, I, I see great things coming from the future. Thank you very much and have a good day. Thanks Adam. Our next speaker today is Shane Colton, the open chain general manager here at the Linux Foundation. Shane's professional accomplishments include sprung heading the licensing team that elevated open innovation network, OIM, into the largest patent non-aggression community in the history. Establishing the, leading the professional network of open source legal experts and aligning stakeholders to launch both the first law journal and the first law book dedicated to open source. Today, Shane will talk about open chain, not only as an industry standard, but as the first IPO standard to come out from our joint development foundation. Please welcome Shane Coughlin. I'm Shane Coughlin and I'm the general manager of the open chain project. I'm delighted to be here with you today to talk about open chain, not only as an industry standard, but as the first standard to come out of our joint development foundation. So let's start at the beginning. Open chain has been in market since October, 2016. This industry standard has focused on open source license compliance in a short but effective specification. Just seven pages long, we've identified the key requirements of a quality open source compliance program. Now, open chain might be a short industry standard, but it is a comprehensive one. Everything that we have included in the open chain standard is based on real world experience from user companies out there. Now, if you think about it, we have around 25 years of experience around open source. Some of this experience is based on deploying products. Some of this experience is based on working with projects. One thing that has been consistent is that in using open source licenses, everyone has been trying to optimize their work. They've been trying to do their best to meet different requirements and to do so in a timely manner. However, trying to do it on your own, company by company, is inherently inefficient, especially when you consider the global supply chain. The supply chain is made up of incredible amounts of companies. One product might go through 20 to 40 companies before hitting market, chip makers, board makers, people who make additional components, the people who provide drivers. It's a long supply chain. If everyone is doing their own thing with open source license compliance, well, first of all, it's hard to predict what your suppliers and your customers are doing and what they need. It's also hard to predict what processes are in the right place and solid enough for your use cases. The result is that in the past, we have seen license compliance challenges. On an individual company level, perhaps it's about maturity. On a supply chain level, it's really about consistency. Open chain, well, it identifies the inflection points where it's important to have a process in place. It helps to contextualize how you deal with inbound, internal and outbound open source code, whether you're deploying it in a product or a solution. We brought together hundreds of companies in drafting and initially deploying this standard. It has been remarkably successful as a de facto industry standard since October 2016. We've seen a global community come to life and set up work groups in areas like automotive and tooling. Equally important, perhaps more important, we have seen very active local communities form in China, Japan, Korea, Taiwan, India, Germany and the UK. Companies, user companies came together to try to ensure that not only were the important process points identified, but where appropriate knowledge was shared and recorded. One good example is that we have reference training slides. You don't have to use these training slides to have a quality open source compliance program. You don't have to use them to be open chain conformant, but open chain does require training. And if you need some inspiration, these reference training slides built from material provided by companies such as ARM, Qualcomm, Samsung and Royal Philips Electronics, it's available. And in the open chain project, our standard of course is not editable. We edit it through a formal process with a work group and votes on the steering committee, but our reference material to help inspire you on training policies, checklists, all of that is CC0. It's effectively public domain. Because we have had a very active community and because we've seen a lot of growth since October 2016, we had the feedback that we needed to make open chain better. In some places we adjusted language to make it easier to translate or to read if you're a non-native English speaker. In some places we refined a few of the terms to help ensure that companies which are not in the software field, which are very different to the companies we're used to seeing around Linux Foundation, well that they could use the standard too. From tobacco companies to medical companies, from banks to defense, we've had all types of engagement and taken all kinds of feedback. By April 2019, we had the second generation of our standard. It wasn't hugely different from the first, but it was refined. And this version of the standard we knew could work across all industry areas and for companies of any size, especially in the context of working in areas where English is not a first language. We built on this standard with additional reference material. There's over a thousand documents in our GitHub repository, our we call it reference library. By April 2020, we were fully confident that OpenChain as a standard was done. It was ready for wider deployment to scale from hundreds of companies to thousands of companies. And the best way to do this was to enter a formal standardization process. So we did. Joint Development Foundation, Foundation that has existed for a while is focused on helping specification projects like OpenChain enter standardization processes such as ISO. Indeed, it has been part of the Linux Foundation ecosystem for about a year now. And it has become a past submitter, a fast track submitter to ISO since early this year. The great thing of working with Joint Development Foundation was that OpenChain as a project didn't have special domain knowledge about ISO editing, but JDF could connect us with the people that do. We got a past editor to help us reformat where necessary and we got help with the process of taking OpenChain till in market since 2020, sorry, 2019, taking that in 2020 into the ISO process and graduating it as not just an industry standard, but a formal ISO international standard. We submitted in April. April 2020, we went into what's called, and this is a wordy bit, ISO, IEC, JTC1, past transposition process. Put simply, when there's a standard that pre-exists, it's already deployed, it already works, you don't have to go through a 50 or 60 month edit and publication cycle. You just go through around nine months of review, acceptance vote and publication. We went through the acceptance vote, finished end of September, and now we're currently, as of recording this on the 25th of November, we're currently just waiting to hit the go from ISO. We're PRF 5230, which means proof of international standard. And in a few days, we expect ISO to release us under IS and then a number international standard. Long story short, OpenChain in a course of around five years became a popular standard, the first and the only standard to deal with open source license compliance. After four years and a little bit of refinement, it was clear this standard was ready to scale to thousands of companies. In other words, put simply to help every company in the world, dealing with open source to have the key requirements of a quality open source compliance program. To do this, we went into ISO. We did that in partnership with Joint Development Foundation and we're done. We passed the process on the approval vote. We had great support from JTC One, Joint Technical Committee One, and we're the first Linux Foundation ISO standard in 14 years. The last time we did this, we did it directly. We did it with a Linux standard base. Now working with Joint Development Foundation, we've created a process. OpenChain was us, as you could say, dog-fooding it. It was our first time through this process. We had some learning to do, but we've learned it. We've codified it. We've recorded it. And Joint Development Foundation is ready to take other specifications in our ecosystem and bring them into ISO to graduate his formal international standards. As Jim mentioned a little while ago at another event, the next standard coming through JDF and out of ISO is SPDX. SPDX 2.2 has been submitted and will graduate somewhere end of Q1, middle of Q2, 2021. That's news to watch for. But in the short term, you should come away from this talk aware that open source license compliance has an ISO international standard. That you can access information about this standard at www.openchainproject.org. That you can self-certify to this standard on openchainproject.org for free. That there's over a thousand reference documents to help you with your processes, your policy, your training at openchainproject.org. And there's a vibrant community whether you want to be on a global mailing list or a local work team, whether you want to work in English or German or Japanese or Chinese, we've got you covered. Alrighty, it's time to be part of this. It's time to adopt this standard, get it into sales and procurement, talk with your suppliers, make it part of your purchasing, make it part of your pitch as why your company has a great way of managing open source and can be trusted to do so effectively. Remember, this standard is all about user companies solving user company problems. It makes sure open source is efficient. It makes sure it's easy and it makes sure that your resources allocated are minimum while results are maximized. Thank you for listening and I'm looking forward if you're not already part of this to welcoming you on board. Thank you, Shane. Our final keynote speaker today is Yonsep Lee, Chief Technology Officer and Co-Founder of Sci-Fi. Sci-Fi is the first fabulous semiconductor company to build the customized silicon based on the free and open RISC-V instruction set architecture. Yonsep received his PhD from UC Berkeley where he co-designed the RISC-V ISA and the first RISC-V semi-con microprocessors with Andrea Waterman and led the development of the Wacha decoupled vector fetch extension. Today, Yonsep will talk about the technical opportunity of RISC-V. Please welcome Yonsep Lee. Hello everybody, my name is Yonsep Lee. I am Chief Technology Officer at Sci-Fi. It's great to meet you all today. I am very excited to talk to you about RISC-V and to convince you that the time is now for you to help out RISC-V. It's truly transformative times where the compute requirements are exceeding Moore's Law. Look at this graph over here. The CPU performance basically has plateaued since 2015 while we continue to imagine new applications that need more compute requirements than we can even afford. AI is expanding from data center to the edge. Growth and embedded endpoints are tremendous. All these trends are forcing us to shift away from general-purpose compute platforms. Companies are vertically integrating, trying to build highly optimized products, design domain-specific architectures to build workload-focused platforms. What this means to me is that we have all the ingredients for a big disruption in our industry here. This brings us to this inflection point where RISC-V, the free and open instruction set architecture, is gaining momentum and adoption. RISC-V is a modern, clean slate design that delivers scalability and superior performance, power and area efficiency compared to computing technology. RISC-V is engineered for practical use cases across microcontrollers, application processors, and high-performance computing platforms. But all in all, it is the RISC-V's openness and lack of proprietary lock-in that encourages long-term adoption, that is attracting a large community of contributors to RISC-V. So practically what this means for companies that are thinking about using RISC-V or actually using RISC-V is that RISC-V reduces the cost of software through community leverage and broad reuse. So since the start of the RISC-V Foundation since 2015, we have gathered more than 750 foundation members across 50 countries. The 750 members are split across 300 companies and institutions and 450 individual members. 2020 is the 10th anniversary of RISC-V and in the past 10 years, RISC-V has been used in many applications and vertical markets. At Sci-5, we have more than 200 design wins with 80 companies including six of the top 10 tech companies. I'd like to mention a couple of these applications and vertical markets so that you can get a sense of where our technology is being used. FPG Harding Cores, augmented reality, audio processing, Wi-Fi Bluetooth, data plane processing, industrial robotics, human interface design, networking, edge AI controllers, voice recognition, smart cities, fast storage, internet of things, satellites, you name it, RISC-V probably is used in your favorite application or vertical market. It is our technology that enabled RISC-V to get into these applications and vertical markets, but most of all, the most important part was the RISC-V ecosystem that enabled all these use cases. So let me walk through the current state of the RISC-V ecosystem starting from embedded. We have great support of RISC-V in various real-time operating systems and trace and debug IDE tools, both in open source and commercial. Today, a couple of open source projects that have RISC-V support that comes to my mind are RISC-Free, RTOS, RTEMS, RIOT, and Zephyr. On the commercial side, Sci-5 has been working with partners such as IR Systems, Seger, Lauterbach, Wind River, Green Hills to design RISC-V solutions and delivering them to our partners together. Switching on to the Linux and application RISC-V ecosystem side of things. Starting from bootletters, we have Corboot, Uboot, UEFI, TianaCore, which is an open source implementation of the UEFI, have RISC-V support. On the distro side, we have Debian, Fedora, Ubuntu, Gen2, Suze, OpenWRT, FreeBSD, NetBSD, with RISC-V support. Let's take a closer look at Debian. Debian builds 95% of packages on RISC-V. This is an important milestone in becoming a normal architecture. Last year at the RISC-V Summit, Carlos had shown Docker and Kubernetes on Debian RISC-V, working on high-five release development board from Sci-5. Looking into Fedora, in 2018, Western Digital has done a Fedora desktop tutorial. The most recent news in 2020 is that the UEFI boot works on high-five release and QEMU. Look at this picture over here. This is the genome desktop manager working on Fedora RISC-V on top of the high-five release development board. At Sci-5, we have taken RISC-V ecosystem development very seriously from day one, and that's one of the main reasons why we started the high-five development program. Starting from embedded development, we have launched high-five one development board in 2016, and subsequently, the high-five one revv with Wi-Fi and Bluetooth support. On the application and Linux development side, we have launched high-five release development board back in 2018, and we have worked with partners like Microchip to develop the high-five release expansion kit with Pull-A-Fire FPGA to provide IOs and capabilities to extend the high-five release development board to design your own domain-specific computers. All in all, these high-five development boards had enabled the first wave of first-five ecosystem development. Switching to the RISC-V software, State of Things, we have pretty much all the important open-source software projects having RISC-V support all upstream to their respective projects. Just to name a couple of few projects that have RISC-V support are GCC, LLVM, GDB, Binutils, NewLib, GLFC, Linux Kernel, and QMU. All have RISC-V support for their respective upstream open-source repositories. At Sci-Fi, we have a couple of software products as well. These are the four pillars of our software products starting from Freedom Studio, which is our Eclipse C and C++ development environment, which integrates the RISC-V cross-compiler, OpenOCD debugger, Sega J-Link debugger, QMU emulator with the Freedom ESCK software package. Freedom Tools is Sci-Fi's RISC-V development tools package, which integrates all these sub-components and is released on a normal cadence. Freedom ESCK is our bare-metal software development kit. Freedom USCK is our Linux software development kit based on Yachto and OpenEmbedded. I have prepared a short video to show you the state of the current RISC-V software ecosystem, so let's take a look. Freedom Studio is Sci-Fi's free development software development IDE. Freedom Studio bundles all the tools necessary to get started developing software on RISC-V, whether you are using high-five series boards or an FPGA board with an IP package downloaded from Sci-Fi Core Designer. Freedom Studio provides access to all the advanced debugging features in Sci-Fi cores, including trace, peripheral viewers, advanced hardware triggers, and performance counters. With Freedom Studio, you'll be creating, building, and debugging RISC-V in minutes. It's using the J-Link GDB server to communicate with the J-Link on this board, click debug, and essentially the J-Link GDB server will connect to the target and download the project or the code. So if you're looking for a sequence diagram-like feature, we have something a chart that's built in that will show you the flow as it goes from for example, Function 10 here back up to in essence main and then back down to Function 11. What I have here is the IR M-Babbit Workbench for RISC-V. When you start M-Babbit Workbench you have this information center with some additional information, product explorer, user guides, example projects. We may have support for all cores here from Sci-Fi. If you look under the view menu, you will have all the capabilities. You have information about the call stack, breakpoints that you are using. We of course support data breakpoints. You can look into the memory, you have all the registers, everything very easy and easy to use. Hope you enjoyed the video. RISC-V has made tremendous progress in the past five years and I personally wanted to say thank you for your contribution. Okay, let's switch gears and talk a bit about the future of RISC-V. Personally, I think the name of the game is to capture the core of the next generation leading compute platforms in intelligent edge, storage, mobile, high-performance computing, networking, embedded, automotive and 5G base station. The key to success here is having the RISC-V software ecosystem and the RISC-V ecosystem for these applications and vertical markets ready to go. To that extent at Sci-Fi, we have launched the High-5 Amash Development Board, the next generation RISC-V Development Board last October. This High-5 Amash Development Board has the Sci-5's FU740 processor here integrates 8GB of DDR4 memory with four of the USB 3.2 Gen 1 ports, Gigabit Ethernet, Micro USB, a Micro SD card slot here and a by 16 PCIe expansion slot by PCIe Gen 3 by 8 lanes and an NVMe M.2 slot and an M.2 E-key for Wi-Fi and Bluetooth expansion capabilities. This all comes in a mini ITX PC form factor with an ATX24 pin power supply connector. High-5 Amash Development Board is a result of curing your feedback so what we've heard from you is you love the Linux-capable RISC-V Development Platform but would like a bit more advanced features such as more processing capabilities, high-speed IOs with expansion capabilities pretty much coming in an industry standard form factor and out of the box software has to work. This is a result of the High-5 Amash Board here and now let's take a look at the FU740 SoC in more detail. This SoC integrates four of the U74 application processors with an S7 embedded processor. The S7 series CPU is our 64-bit 8 stage deal issue superscalar RISC-V cores. All these five cores are coherently backed by a 2 megabyte L2 cache which is backed by a DDR4 memory controller. The SoC integrates a PCIe Gen3 by 8 controller with a gigabit ethernet controller and a bunch of peripherals. Now let's take a look at the High-5 Amash Development Board in action. In a couple weeks you can put your order online at CrowdSupply or Mauser. For more information just go online and search for High-5 Amash or visit sci-fi.com for slashboards. As I mentioned before, RISC-V software has made tremendous progress over the past couple years but we could definitely use your help. To be more concrete the RISC-V porting work has begun on UEFI, V8, Java and Android but obviously these projects could go much faster if you're willing to jump in and help out. In conclusion, let's go build the RISC-V ecosystem together for a better future. These look like big mountains to climb but let's not forget it's about this virtual cycle here. Start from RISC-V a free and open architecture add your commercial innovation here and with community contribution we'll end up with a much stronger base for a better future. I'm counting on your support. Thank you very much. Once again thank you all for joining us here at Open Source Summit Japan and Automotive Linux Summit and another big thanks to our sponsors. We hope you had enjoyed keynotes and encourage you to join our breakout sessions beginning at 10-25 a.m. in Japan time. We very much hope to see you in person next year and enjoy the reminder of the conference and have a wonderful day. Thank you so much and see you next year.