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


Hello friends, welcome to the session. I am Alka and we are going to discuss matrices. We have to compute the following Our matrix 1 2 3 is multiplied by matrix 2 3 4 now Let's start with the solution on multiplying those these two given matrices we get 1 into 2 1 into 3 1 into 4 and 2 into 2 2 into 3 2 into 4 3 into 2 3 into 3 and 3 into 4 This is equal to 2 3 4 4 6 8 6 9 12 therefore The product of 2 given matrices is 2 3 4 4 6 8 6 9 12. Hope you understood the solution and enjoyed the session. Goodbye and take care


Welcome to virtual university and welcome to your English class. If you look at the title of today's lesson, it is ways of organizing texts. And we are going to talk about how to write about time and how to write about process. In today's lesson and in the next few lessons, we shall examine the main body of the essay. We shall examine the main body of the essay in great detail and give you practice. First, in using common ways of organizing texts, organizing texts as a whole. And then you will be provided with plenty of examples of different types of texts which will help you to see the principles on which these texts have been organized, on which these texts have been based. Now learning to write in English is not as difficult as it seems. Of course, no one expects you to write like a Shakespeare or D. H. Lawrence, right? Especially in a language which is not your own. You are not aiming at writing great literature. Your need is to write clear, accurate English which has a central idea and other related information and which gets your meaning across to your readers. Now, here I would like to add a note of warning. Writing is a complex activity and it cannot easily be broken down into a series of skills and sub-skills for teaching. Now, no writing course will ever teach you everything you need to know in order to become a competent writer. But there is no reason why you cannot learn all there is to know about effective writing. In the last couple of lessons, we have been looking at introductions and conclusions of essays. Good introductions and conclusions, they hold up the ideas and keep the evidence in order. If you take away either the introduction or the conclusion and you will notice that the whole structure of your essay will fall. But introductions and conclusions do not make up the whole essay of whatever composition that you are writing. The introduction and the conclusion, they only give directions and a sense of finale or a sense of finality. And between these two ends of an essay, we use a system. The body of the essay is written according to a system or a pattern. Now, let me repeat what I said. In the past couple of lessons, you have learnt how to write introductions and you have learnt how to write conclusions. And between the introduction and the conclusion, there is a whole body, the main body of the essay. If you take away the introduction and you take away the conclusion, the body will lack something. Now, we have had practice in writing introductions and writing conclusions. In today's lesson, we are going to talk about how to write the main body of the essay. And that is done according to a system or a pattern. There are ways of writing the main body of the essay. And once you choose a pattern for yourself, you must stick to it. But it is also possible to combine a number of patterns in one essay. Now, for the sake of recall, let us look at the structure of an essay. You have the introduction, which is made up of the thesis statement and the general statement. And then you have a number of paragraphs. It all depends on your topic, your purpose of writing. You can have two paragraphs, you can have three paragraphs, you can have five paragraphs. You can even have more than five paragraphs. There is no limit. It all depends on the topic you are writing and the purpose of your writing. Now, if you will look at your screen, you will see the body, the structure of the essay. Again, you have your introduction, your conclusion and then the rest of the body, the main body. And today we are going to concentrate on the writing of the main body of the essay. Now, there are three main patterns for organizing the body of the essay. There are other patterns as well, but we shall only concentrate on those that are most commonly used. And these are, if you examine writings of people, you will find that three types are most commonly used. One is what is called linear relationship, right? And then spatial relationships. And number three, classification. These three are the most common. There are others as well, but in your course, we are going to concentrate on three only. Now, when we talk about linear relationships and they are of four types. They describe time, chronology, chronological descriptions, descriptions of processes. And then you have processes in cyclic consequence and you have cause and effect. So, let me make this clear. Linear writing is of four types. Number one that describes time, events taking place in time, which is called chronological writing. Then we have writing which describes process in linear sequence. And we have descriptions of process in cyclic sequence. And number four, we have writings which deal with cause and effect. Second major type is the spatial relationships which describe things in space, right? And we talk about classifications and definitions and others, right? And the third one is comparison and contrast. We look at the first one, chronological or events based in time. This is one of the most often used patterns to reorganize the body of an essay. This arrangement begins with what happens first and ends with what happens last. This type of organization is very common in fiction writing, which is, as you know, straight narration. This type of writing, this type of organization is also used in autobiographical essays when you are writing about somebody's life story or your own life story. This pattern of writing is used in process themes and in history reports. Historians frequently use this pattern of organization.  And chronological sequences can be written in different ways. We normally think of time as moving forward in a straight line. And a chronological sequence follows this view of time. This is what they say, a linear relationship, linear meaning coming in a straight line. Now, for practice sake, you will see a text on your screen, read it and complete the diagram which is given at the end. And notice the phrases or words that show chronological order, chronological meaning, time. There are some words or figures in that passage which show you the sequence in which the events took place. As long ago as 1779, John Frear, an English country gentleman, discovered at Suffolk several bones from extinct animals associated with stone age flint tools. He published his findings in 1800. Frear's report was not appreciated for another 60 years. But now Frear is known as the founder of prehistoric archaeology. This passage is taken from the journal New Scientist published from London. You have four boxes given at the end. One of them is filled. Which words or figures show the chronological order in that passage? The first one is as long ago as. And you have the figure 1779. That is a phrase plus the figure showing you a certain period in time. And the time is 1779. And you can fill the first box with the letters 1779, the figure 1779. And you go through the text and you will find that the next time that is mentioned is in 1800. That is already done for you. And the following one would be another 60 years. So 1800 plus 60 years would be 1860. And then the last sentence, you have a word over there which again is related with time. And you can fill the fourth box with that word. And that word would be now. So you have time moving from 1779 to 1800 to 1860 to now. And the phrases were as long ago as in 1800, another 60 years and finally the word now. Now that passage was arranged in chronological order in a manner which showed how events took place. Now we will look at ways of writing chronologically. In our daily lives we see time as moving in one direction only and that is moving forward. What goes past us we see as history because it appears to us that we are moving forward into the future. Now there is nothing that we can do to change our relationship to time. However, when we write we can play around with time as we wish. And we can move the writing forwards and backwards in time according to our purpose in writing. I hope you have understood my point. Let me rephrase it for you. Actually in real life we think we are moving forward in time, right? But when you write, in writing you can play around with time. You can begin from the past, move on to the future, then go back to the present, then move forward. That is something that you can do in writing, right? Now for the sake of practice there is a passage in front of you on the screen. Read it and see which information or which sentence is not... There is something in that passage which is not in an acceptable order. The whole thing is in a chronological order but there is one sentence that disrupts that chronological order. Quickly go through the passage, the sentences are numbered for you and you can spot the sentence, the information that is not in an acceptable order. You are familiar with this passage because this is from the history of computers which you had earlier on in your reading sessions. Now look closely, the first sentence begins with in 1930, right? And then we move on, the next period in time is 1944 which is in sentence number 3. You move further down the passage and you come to sentence number 4 or 5 where it says another important advancement in computers came in 1947, fine? And the last sentence, number 6, in 1946, now that there is the anomaly, there is what is wrong. Sentence number 6 should not be the last sentence, in fact it should be in the place of sentence number 5. So what is marked as number 5 should actually be the last sentence. I hope you have understood what I meant by writing in chronological order. Let us look at another example. This example that you just now saw, the sample, this was of writing in chronological order. Now you will see another form of writing. It is also in chronological order but in a different way. It is the story of a Kashmiri immigrant, a Kashmiri immigrant's story. In 1947, Ahmad Reen Bhatt, a poverty-stricken 20-year-old farm worker, left Kashmir for Pakistan. What the future held in store for him, he did not know. However, he did know that it could not be any worse than the past. He had grown up during the cruel rule of the Dogras in Kashmir and had known what it was to be hungry and jobless. He had watched his mother die of tuberculosis a month before. His father had died a year after Ahmadine was born. There was nothing now to keep him in Kashmir. And so, on a cold March morning, he got into a bus bound for Rawalpindi. In years to come, he would remember this moment. Now, if you look at that passage, you will notice that the passage is talking about time. It starts with 1947. Then it goes back into the past rather than starting in the past and ending with 1947. Now, this use of unexpected time sequence. This was an unexpected use of time sequence. It allows the writer to show the relationships between events which are more strongly. It allows the writer to show the relationships between events in a more stronger fashion. And it enables him to make the text more dramatic. Now, if the texts were in the expected sequence, had this text been written in the expected sequence, what verb tense would you expect to find used? Because the writer is going back to 1946-47. So he should have used the past simple. But you find that the writer keeps moving. He uses two kinds of tenses. Which of the tenses are used in the text? Is it present, present perfect, past, past perfect? If you look at the text again, you will notice the writer uses the simple past and the past perfect. Now, the writer of this passage, he develops an unexpected sequence because he wants to highlight the fact that Ahmadine but was forced to leave Kashmir for Pakistan. The way his leaving is highlighted, it captures the reader's attention and makes the reader want to find out why he was leaving and why he was poverty stricken. In general, writers use unexpected chronological sequences when they want to emphasize something other than time. Did you get the meaning? Why is the writer using an unexpected chronological sequence? Writers do such things because they want to emphasize. They want to emphasize something other than time. So, the moral of the story is in order to emphasize even if you are writing in the chronological mode even if you are using the chronological order, you, the writer has the liberty to use an unexpected time sequence. Now we shall look at another version of the same story. And you compare the two versions and see which one is more interesting. Is the one that is very, very logical, is that interesting or the one that you had just now where the writer used an unexpected time sequence. See for yourself which one is more interesting. Amitadeen Bhatt was a bright but poverty stricken 20-year-old farm worker who grew up during the Dogra rule in Kashmir. He knew what it was to be hungry and jobless. His father had died in 1928. He had watched his mother die of tuberculosis in February 1947. There was nothing to keep him in Kashmir. So, on a cold March morning in 1947, he got into a bus bound for Rabalpindi. In years to come, he would remember this moment. Now, I am sure it was the one, the passage where the time sequence was used in an unexpected manner. That was more interesting. What you have looked at is time-based sequence. Now, there are many time-based sequences which you have studied and you are familiar with. Example, if you remember sometime earlier, we talked about making carrot pudding. The life, the life cycle of a butterfly. The life of a famous movie star or a politician or a sports person. Now, we will look at another linear pattern of organization which is known as process writing or using the process order of organization. A process like a chronological sequence, it involves linear relationships, linear meaning again in one line, one thing coming after another. Now, again, like chronological writing, we think of time, we think of processes as moving forward in a logical step-by-step process. A process is usually presented as a flow diagram. Look at this flow diagram. It is about mending a punctured football. You've all played football and you've often had a football that is punctured. If you look carefully, it describes the process of mending a punctured football. And notice, the description is step-by-step. First, take the bladder out of its cover. Next, inflate it a little. Then dip it into a tub of water. Press to find out the hole in the tube. Then you mark the spot with a marker, the spot where the hole is. Then you let out the air and you dry the bladder.  Then you apply a rubber solution to both the marked place in the tube and the rubber piece. And you let them dry. And then you place the rubber piece onto the bladder and you press the tube very hard and you have mended the puncture in the football tube. Now if you noticed, it was a step-by-step process. One step coming after the other, all arranged in a logical order. You do the same when you are cooking. You first follow the first instructions, then you follow the next one, then the next, then the next. Right? Now, another passage for practice. You convert the following process as a flow diagram by filling in the boxes. Here you have the whole thing in text form. It is written. You can convert this into a diagram, a series of boxes and you fill them out. Again, the passage is familiar to you. It is taken from computers and you had plenty of practice in your reading sessions. It is steps in problem solving. You read it yourself. I shall not read it out for you. Look at the passage. Look at the words that give you the clue or the clues. The first one is, next the programmer must construct an algorithm. A flow chart or a block bra. Then you have, this is followed by, that is the next step. This is followed by, key punch the program. And then it gives you the alternative as well. And then it says that the program must be tested. This is followed by the next step, which is print out. And you have the words, the last step. That is a clue for you that this is the last step in problem solving. And the last step is to add the data to the program and run the program. We have this, you can write this text in, you can convert it into a flow chart. First, define the program. This is followed, the next step is formulate an algorithm or a flow chart. An algorithm flow chart. The third step is translate the algorithm into a computer program. Followed by step number four, which is key punch the program and key it in at a terminal. And the fourth one is, the fifth one is test the program, correct the bugs. And the last one is add data and run the program. Now, when you write up a process in a text, it will normally be in natural time order. That is, starting at the beginning of the process and continuing step by step to the end. As in the example that you have just seen. Now we shall look at ways of writing a process description. One way of writing up a process is to produce one sentence for each step in the process. One sentence for each step in the process. Now, in the last paragraph that you looked at, the last passage, which was steps in problem solving, you would easily have a text of six sentences. However, such a text would be very boring as every sentence would state one step and every sentence would have the same shape as the others.  One solution is to put several steps into one sentence and you can mark the steps to make them clear for the reader. When you are writing, you must not always, you must ask yourself this question. Am I getting this information across? That is one question. You must also ask yourself, am I getting the information across in a clear, interesting form? Now, let me repeat what I have said for the sake of clarity. Writing, process writing can be very boring if you write one step in one sentence. That means all your sentences, if there are five or six steps, you will have five or six sentences and each sentence will be shaped like the other and it would make very boring reading. Now, the thing is that you should, as a writer, you should keep asking yourself, am I, whatever I am writing, is it, is the information going across in a clear and interesting manner? Now, to help you answer these questions, you must keep in mind a few principles of communication and what are those principles of communication? They are, number one, make everything clear to your reader or your listener. In our case, since we are dealing with writing, make everything clear to your reader. Number two, your reader does not need to be told everything.  You assume that he has knowledge of the world. So, number one, make everything clear to your reader. Number two, you don't have to tell your reader everything. Now, to check whether you have been successful in conveying information about a process, your choice of transition words will be important. Words that convey a sequence such as then, next, after this, they make the sequence in a process very clear. They make the sequence in which the events or the shapes that are taking place in a process, how they occur, they make it very clear. Now, on your screens you will see a table and that table gives you some sequencing words that are to be used when describing a process. I know you will yawn when you look at those words. You will say, well, we are familiar with these words. We've been looking at them since day one. But because they are important, because they are used in writing, that is why I am showing you those words again. In the beginning you have words like first, firstly to begin with initially. And in the middle steps you have secondly, thirdly, next, then subsequently, after this, before this, at the same time. And at the end you use words like lastly, finally, at the end. Now, these sequences are usually placed at the beginning or near the beginning of a sentence. These transition markers are usually placed at the beginning or near the beginning of a sentence. Words showing only sequence work as signal or signposts for the reader. Now, if they give advance warning, if they give advance warning of the relationships being used, it is up to the writer to decide which sequencer, which sequencing word to use to make each step of the process clear. That is one way. Or the writer may decide that sequences are not needed because the process is described in natural time order. And the reader's knowledge of the world will make the sequence clear to him or her. Now, you will see a text that departs from the usual order or sequence. This I have done deliberately to highlight a certain feature or stage of the process. Here the writer does not follow the usual pattern. He uses no sequences till the fourth sentence when he specifically uses the sequencer words before and first. You should notice that the writer does this to highlight the storage stage of the process. The passage is about solar heating. Number one, the first sentence. The scientists have worked on solar heating. Number two, one such attempt was made in 1949 when a house was designed which was heated by using the energy from the sun. In this house, energy from the sun was absorbed by a large area of blackened metal sheets which were covered by double plates of glass. Air circulating behind the metal sheets carried away the heat. Before the heat could be blown around the house, it was first stored in large tanks containing globbers salt, a given volume of which can hold eight and a half times more heat than water. Now if you look at that paragraph, that paragraph has four sentences. And the writer does not use a sequencer or a transition word in sentence one, two, three, till he comes to the last sentence. And over there he uses two words. Before the heat could be blown around the house, it was first stored in large tanks. So as I said earlier, it is entirely up to the writer at which point he wants to use the sequencer words. And he uses them at a point where he wants to lay emphasis. Right. Now what kind of grammar is used in process description? When writing a text about a process, usually the present simple tense of the passive voice is often used. Now this is especially true in objective scientific descriptions. In scientific descriptions, who does the action, that is the agent, is not considered important enough to be mentioned? Or where there is not a specific agent or order or doer, sorry. Right. In objective scientific descriptions, the doer is usually not emphasized. Also, when a description of a process is given, it is usually assumed that the process will be the same. No matter who does it. And it is the passive voice which is usually used as it allows the choice of not mentioning the agent of the action. But even here, sometimes for the sake of clarity, an agent has to be stated. Now remember, what is important in writing is clarity. Even in objective scientific writings, you are required at times for the sake of clarity to mention the doer of the action. Now we shall work at a number of sentences where you will have to state if there is an agent or not in that sentence. Practice. Another practice session. You have a number of sentences. Sentence number A. Rice is harvested out in the fields. In that sentence, is there an agent? Is the person doing the action of harvesting mentioned? No. In that sentence, there is no agent. So that sentence is without an agent. B. Sentence B. Higher laborers load the rice onto bullock carts. Higher laborers load the rice onto bullock carts. Now in that sentence, is there an agent? Or is there no agent? There is one. There is an agent. The agent is mentioned. The doer of the action is mentioned. And the doer is, here, hired laborers. Sentence C. The cart drivers bring the rice to the factory. The cart drivers bring the rice to the factory. Now is there an agent in that sentence? Or is there no agent? There is an agent and the agent is drivers. Take sentence D. The laborers put the rice into the threshers. The laborers put the rice into the threshers. Again, see if there is an agent mentioned. And you will notice that there is an agent. And the agent is laborers. Sentence E. The rice is threshed by machines. The rice is threshed by machines. Is there an agent? No. There is no agent in that sentence. That sentence does not say who the doer of the action is. Sentence F. These machines are regularly maintained. These machines are regularly maintained. Now in that sentence, is there an agent mentioned? Or is that sentence without an agent? And if you look carefully, you will see that no agent is mentioned. So out of those six sentences, only three had agents mentioned over there. Now in today's lesson, we looked at the main body of the essay, how that is organized, and we looked at different patterns of organization. We looked at chronological order, how writing can be organized according to time, according to a sequence, one event taking place after another. And we even looked at samples of writing where an unexpected sequence of time was followed. And we learned that that was for the sake of emphasis. Writers can break the rule and they need not write in a chronological order. They can move backwards and forwards. And the next pattern that we looked at was writing for a process. And over there, you noticed that it was a step by step pattern of writing. One step followed another. Sometimes we even looked at a sample where we saw that the writer uses, right at the end, in the last sentence, he uses words to show. He combines a number of steps in one sentence. And the third thing that we looked at was cyclic, which we are going to look at next time. But the third thing that we looked at today was the use of the agent, the tense, how when writing processes writers usually write in the passive, in the passive voice, because it saves them the trouble of mentioning who the doer of the action is. And you looked at different samples. You looked at sentences in which there were no agents. And with that, we come to the end of today's lesson. Next time we shall follow cyclic writing. We will continue with patterns of writing. How writing is organized according to different patterns. Next time, inshallah, we shall look at spatial and cyclic forms of writing. Till then, Allah Hafiz. See you next time.


Never again for the next six months ask a why question why is my favorite I know and how's that working for you You can answer all the whys in the world and why doesn't create momentum change your whys to what instead of why am I thinking this? It's what are five choices available to me right now and of those five What can I say yes to the parts of your brain that are on fire that don't let you move will go? Oh, we have choices once you get going. You're gonna build compound momentum very good I can already like sounds like it feels better. Yeah


Pan Am Flight 103. Pan Am Flight 103. Semtext. Pan Am Flight 103. Let's see what this is all about. Death over Lockerby. Wow, wow, wow. We're going into Libya, I believe. Wow, wow, wow. Card number 16. Death over Lockerby. Investigations into who plays plastic explosives on Pan Am Flight 103, which blew up over Lockerby, Scotland on December 21, 1988, killing all 259 people on board, are still ongoing. But the tragedy is widely thought to have been a terrorist attack on a U.S. target. At various times, stories have surfaced, implicating Syrian President Assad, Libya's Colonel Qaddafi, Iran's Ayatollah Khomeini, and Palestinian terrorist Ahmet Jibril. In 1990, the DEA looked into claims that one of its agents had smuggled explosives on board, believing it to be a heroin shipment, part of an undercover sting operation. An interfall, an anti-terrorist consulting firm which undertook an investigation for Pan Am's insurance carrier, concluded that the CIA was warned that a bomb had possibly been loaded onto the plane in Frankfurt, Germany, but allowed the flight to continue to protect the heroin shipment by Monzer Al-Kazar, a Syrian arms and drugs smuggler who had successfully negotiated a May 1989 swap of arms for French hostages. Al-Kazar had earlier received 1.5 million from Iran contra figures, figures Richard Secord and Albert Hakim for providing 100 tons of arms for the Contras. The interfall report named Army Major Carl's Mackey as heading an eight-member CIA team in Beirut, who while trying to gain release of CIA hostages had uncovered other CIA agents protecting Al-Kazar's drug pipeline in hopes that he would aid them. Mackey's team planned, quote, to bring the evidence back to the U.S. to inform the government and to publicize their findings if the government covered it up, end quote. At least five, and possibly all eight, of Mackey's team were aboard flight 103 when it crashed. What? Oh no, we gotta read that again. The interfall report named Army Major Charles Mackey as heading an eight-member CIA team in Beirut, who while trying to gain release of U.S. hostages had uncovered other CIA agents protecting Al-Kazar's drug pipeline in hopes that he would aid them. Mackey's team planned, quote, to bring the evidence back to the U.S. to inform the government and to publicize their findings if the government covered it up, end quote. At least five, and possibly all eight, of Mackey's team were aboard flight 103 when it crashed. Oh my god, I know a little bit about this. I'm not going to say what I've heard, what I read about this. This stuff was coming out way back when they were trying to blame Qaddafi for the bombing. Qaddafi took the rapboard for a deal that he cut where the Western government said that they would not try to overthrow him as long as he took blame for the Pan Am flight and he did take blame for the Pan Am flight. So Western governments made the Libyan government, Qaddafi, the Pazis for Pan Am flight. This thing is revealing a little bit of information that I've never heard about. Wow, wow, wow. Holy Kamoli, Pan Am flight 103. If these weren't trading cards, this would probably not go on CensoredTube, but they are trading cards from a comic book company and they're gonna go on CensoredTube.