Good morning DrupalCon! I hope you had a fantastic Tuesday night in Nashville. I'm Rachel Lawson, I'm the Drupal Association's community liaison. I only started in January so I'm still learning everybody. And although I've been in the community for a decade, this is my first DrupalCon North America. I don't know whether that means I actually get extra points in the trivia tomorrow night. I wanted to just take a couple of minutes to talk about community and particularly a phrase that keeps coming up that we all try to live by, come for the code, stay for the community. Now I did come for the code for Drupal about 10 years ago and I used Drupal for a little while and then just to make my life even more complicated, I started to get involved in the community right at the same time as very publicly coming out. Now the first time I went to a Drupal camp, I was scared. I was scared because I was different or I felt I was different. I wasn't sure whether I would be welcomed or anything like that. I didn't know these people. It was Drupal 7 Camp in Leeds in the UK where I grew up. It was amazing. The people in there were so welcoming to me, even though I felt different. People like Dan Smith at the front there from my security team, people like Andrew McPherson a bit further down the line sat next to me when I used to have longer head dark hair before I started coloring it. Andrew McPherson is one of our accessibility maintainers. They made me feel welcome and it mattered to me. I kept coming back. I went to more Drupal camps. This is actually Frontend United in Copenhagen where I first was welcomed and encouraged to take part in Drupal contribution by amazing people like Lowry Eskola I think is here and Christina Chimales. They helped me feel that I could do this. I didn't think I could do code commits. It was like no way. Absolutely. They made me so that I could. It mattered to me. It mattered to me so much that even when I was unable to go to an event Frontend United in London it mattered to me that the organizers of that event in London people like Justine Pocock and Karen Leach actually came into the hospital while I was otherwise indisposed and brought me cakes and flowers and most importantly they brought me freebies of the camp t-shirts and stuff. It's one of my favorite t-shirts even though I never went to the event. It mattered. It made me feel welcome and it matters to me now being able to get involved in helping mentor others which I got involved in first of all at Drupalcon Amsterdam was really important to me. It matters to other people how we welcome them and encourage them in our community. I was invited to be fair I did hassle them a lot beforehand but I was invited into the Drupal community working group to help with the community and making sure that we can help resolve differences and so on. People like Adam Hill there and Jordana Fung and George Demet and Michael O'Neill and Emma Carriannis who run that do enormous amounts of work to try and help our community. It matters that we make people feel welcome and don't turn people away. So even though I started off in this community as somebody who just thought whoa I'm probably not going to be welcome here I was and it made a difference. We keep hearing this week and quite a lot actually about ambitious digital experiences. Well for me we only make digital ambitious digital experiences when we all are ambitious about how we welcome encourage and celebrate each other and we need to celebrate our successors. It really matters it matters to me and I hope it matters to you that's all the time I get to talk about things. I'd love to talk about the community more and more and more. I want to be able to talk to all of you but as well as community we are doing some amazing things. We have this promote Drupal campaign and some individuals named there and many companies so far have already raised 54,000 and nearly said pounds then 54,000 dollars of our $100,000 target to actually make Drupal be in front of the people's minds who we needed to be there. I would love to see us hit $100,000 very very soon. Get your checkbooks out. Anyway, some housekeeping because it is the start of another day. Coffee will be in the usual place. I severe a very kindly sponsoring coffee today. Lunch, please remember to eat and drink. You know good to us otherwise. 12 till 2. Usual place. There are some schedule updates. So getting real about agile presenters, Kelly Olbrecht and Sean Eddings takes place at 1045 in room 103B and the camp organiser survival guide presented by Joseph Derbenig at 345 is in room 101E. We couldn't run a camp. A camp? I can't. You can't run camps either without sponsors but cons too. You can't run without sponsors and we're so thankful to all these sponsors and it is a long list and we're very thankful. My goodness it is a long list and supporting partners as well who help us do things like actuallymakedrupal.org. I'm looking forward to meeting some of these people today. That is a long list. We can't do anything without the contributors making code, documentation, all the different things. Contributing is not just code. I need to get back on this list. I've been off this list. I need to do something about that. Okay. And special thanks to our top business contributors of which yet another long list which is great. I mentioned Dan Smith earlier on. Thank you again to our security team. Who's in the security team today here? Oh yeah we've got a few. Okay. Well what I'm going to do now is I'm going to hand over to Lynn from Acquia who's going to introduce you to our keynote speaker. Thank you. Thank you Rachel. Good morning. Morning. Hi I'm Lynn Kaposi from Acquia CMO. Very proud to be a sponsor, one of the sponsors of Drupalcon. And I have a couple of things to tell you this morning. First of all thank you to those of you who joined us at Tequila Cowboy last night. So it was fun catching up. And if yes, excellent. And if you did get there and you may be in need of some assistance this morning I'm happy to announce that we have Acquia Survival Kits. You can stop by the Acquia booth around this. So it's really everything you need to survive a Drupalcon. So there's some there's a little bit of vitamin C. There's hand sanitizer. There's Advil. And some band-aids just in case it didn't go so well last night. So feel free to stop by our booth. But I do have a couple of other reasons for you to stop by our booth. Please come by and say hello. We would love to chat with you. We have a couple of new things going on that we'd love to have you come talk with us about. We also have Drupal certification that's going on. And we so stop by our booth and we can tell you a lot more about that. We have the certification events that are going on. So please join us for that. We also have something new in the booth which is called where we have a this is like a proof of concept that we have from our professional services team. And it's a decoupled starter kit for React. So please come by. Basically it's a way for as a Java front-end or Drupal front-end developer to hook to a Drupal backend. And so it's a new kit that we've created, especially for developers. So please come by. We're just in the process. Again, it's proof of concept but love some feedback. So please make sure you come by if you're at all interested. And I know a lot of you a lot of there's been a lot of interest around decoupled. So please make sure you stop by and talk with us about that. We also have some new things going on from Acquia including our journey product for journey mapping for customer journey mapping. So please come by and ask us about that. We would love to see you and talk with you about that. And we have a giveaway for an Apple Watch. So if the survival kit isn't enough, if the decoupled starter kit isn't enough at least come by and talk with us and and drop your name in for the giveaway for the Apple Watch. So I'm also proud to be a sponsor for what Theresa announced yesterday around the Drupal effort around promote Drupal. Thank you. I was going to say marketing but I don't want to use that word. So around promote Drupal, proud to be a sponsor for that. And I would invite others to participate and sponsor with that as well. So just a quick commercial. At this point I'd like to introduce Steve Francia who's an open source leader and I'm going to let him give his background as it comes up on stage. Please welcome Steve. Okay. We are having technical difficulties. This is not where it should be yet. It's it's changing there but it's not changing what I see. Casey it's not changing what I see yet. I printed it out just in case I can go off my paper. Maybe I should start with that. We'll give him one more minute to try. Always be prepared. That's the secret of my success. That's right. Could you tell me when you do that because I want to go like this every just let me know. It's working. So Drupal has survived and thrived for 17 years because of one simple fact. It has embraced change. Although every open source project is unique there's a single evolutionary journey that all successful projects must go through. I've been fortunate to have been a critical part of the journey of five of the largest open source projects in history. I'm currently at Google as one of the leads on the open source strategy team responsible for the Go programming language. Today I want to share my journey through open source with you. I'll share the lessons I learned, the mistakes I made, and the role Drupal has played through all of it. It's far more autobiographical than I'm comfortable with and I hope you'll stay with me as we experience this journey of open source together. My story begins in the mid-1990s. Janko Jeans and Buffy the Vampire Slayer was the backdrop. I was still in high school and one of my hacker friends had gotten me a job at an early ISP that stands for internet service provider working as a UNIX administrator. This really was the dawn of the modern internet. Netscape 2 was a big deal. It's like 20 years ago. It's not a big deal. It was a big deal because it supported animated GIFs. The central server that ran our entire business was a digital alpha server with a 64-bit processor. This was 64-bit at a time when 16-bit was the norm. Digital Equipment Corporation was successful in their marketing gimmick of creating a search engine just to demonstrate how powerful their systems were at the time. Altavista running on an alpha machine could index the entire web and here I was barely shaving and responsible for running one. I remember that it was nice to look at. Visually similar-ish to Windows 95 which was recently released. I also remember you couldn't change anything. The code was all closed and controlled by Deck who sent periodic updates in the mail on CD-ROM. It was also crazy expensive. Each machine cost north of $25,000 and then there were software licensing fees of over $10,000 per year. That's $60,000 per server in today's money and we had two of them. Some time later we decided that we wanted to add Usenet support to our offering of web email and dial-up for our customers. For those of you too young to remember Usenet in the 90s was pretty much the reddit of the day but like most things at the time it was decentralized. Because Usenet was decentralized we needed to house our own Usenet server and I was tasked with setting it up. Without knowing the demand we couldn't possibly go with another expensive Deck alpha. Instead we decided to explore the free offerings. After reviewing the offerings we decided on running on free BSD running on an Intel x86. Since it was an additive service we felt comfortable taking the risk on free software which at the time was relatively unknown. As an aside we also considered Linux and Laft at its poor networking and overall immaturity. I worked at the ISP for four years and I learned a ton. I learned that Shift ZZ was the best way to exit VI. I learned that Unix admin people weren't that different from the plague from hackers. I learned that well experience matters in a new space everyone has to go through the same process of discovery and learning. Lastly I learned that free software could work just as well or better than proprietary software. In 1998 I stepped away from schooling and computers for two years to do missionary service in inner city Los Angeles. When I returned the world was a different place. Ska left as quickly as it came and was barely a memory for most people. Are you clapping because it came or because it went? I'm not. Free software had a new name. It was called open source. Google had changed the landscape with both its search as well as its approach to scaling using free software on top of commodity hardware. That's really what Google ran on in the 90s. Lamp had emerged as the stack for the internet. During this time period I enrolled in a computer science program at Brigham Young University. I started a software development company. I got married. I had a child. My wife told me not to put the picture in. I said every father or mother in the room knows exactly what's going on with me in this picture. So I did it anyway. I created the first object-oriented PHP framework and I also created an e-commerce CMS product. As the framework wasn't essential to our revenue I open sourced it and called it ZOOP. This was many years before anyone else was doing web frameworks and we struggled to communicate its value to others. I also didn't know how to run an open source project. We struggled to market it though somehow we ended up getting a decent size user base in Asia. I'm glad some people find that funny. We called our CMS super site. It was a mix between Shopify and Squarespace with some very advanced features including block-based drag and drop layout creation. We licensed it to some Fortune 100 companies but ultimately struggled to gain adoption. I'll blame this on my complete lack of understanding how a company should run. I followed what I call the field of dream strategy figuring that if you build it they will come. I built it and they didn't come and I struggled watching inferior products get more attention. Around the same time period another student built a similar CMS also using the LAMP stack. He called his CMS Drupal and unlike super site Drupal was released as open source. Drupal adoption group rapidly. I learned technology changes quickly and if you aren't willing to change too you'll be left behind. I also learned that it isn't always necessarily the best product that wins but the product that is able to reach the greatest number of people. Promote Drupal, right? Then it'll be the best and the most popular. Finally I learned that timing is critical. It's entirely possible to be so far ahead that the world isn't ready for it yet. In 2004 I graduated from college with a degree in philosophy and headed back east. To raise my family which was now four I took a job at a few startups in New York City. In 2006 I joined the second of these startups Portero, a luxury e-commerce company. It was at Portero where my path in Drupal's crossed for the first time. We built a beautiful website powered by Magento for the e-commerce portion and Drupal 4 for the content portion. We actually built decoupled Drupal long before that was really a thing. I built my personal website on Drupal and it turns out archive.org thought the content was important enough to keep but not the style so it looked kind of like this but with my content. I also set up my Drupal.org account and created a Drupal.org plugin and I was both amazed and horrified at the hook system of Drupal 4. I was impressed with Drupal.org and how much development and conversation happened there. I remember thinking that Drupal was pretty powerful and how many things it enabled you to do. I remember wondering if there would ever be a day when people would be paid to work on free software but nobody outside of academia was really paid to do open source yet. I left Portero and joined another e-commerce company, OpenSky. Initially the mission of OpenSky was to create a platform to empower content creators to monetize their following via authentic product reviews and sales. We did all of the sourcing, sales, and shipping while they curated the products they loved and placed an embedded checkout right there in their blog. I actually received a patent for creating the first online distributed checkout. We knew that people loved reading and hearing about what their favorite influencers had to say about products. We thought that if we removed the extra steps it would enable readers to purchase we would do right for everyone. Ultimately it was a flop. We discovered that people wanted reviews but not when they felt like they were being sold. The authenticity, well real, felt artificial when sales were introduced. A few months into the role we needed to pivot the entire company. They had outsourced all of their development previously. It was built on Magento and in spite of a relatively small amount of traffic it was unable to keep up with the load due to a data model that compromised performance for flexibility. Isn't that a perfect gif by the way? The pivot gave us an opportunity to start from scratch. It was a huge bet for the company and most of it rested on my shoulders. I decided we needed to move everything in-house which meant I needed to quickly build out an engineering team and also figure out which architecture to use. A lot was changing in the world. PHP 5 brought true object orientation to PHP. Drupal 5 was released which I upgraded my personal site to and Ruby on Rails was released and all of a sudden web frameworks were in vogue and for the first time since the 80s there was a movement to build an alternative to relational databases. I had the idea to use open source as a recruiting tool as in hiring experienced open source developers. I reached out to Nate, a fellow PHP developer and New Yorker and one of the primary authors of the cake framework. We went out to lunch. I didn't know it at the time but this lunch changed the entire course of my life. During this lunch he told me about his new framework, Lithium. We also discussed these emerging databases and I told him I was pretty seriously considering using Cassandra or Tokyo cabinet. Nate told me about an even newer database that he thought I'd like, MongoDB. We ended up building our platform on MongoDB in Symphony 2. We were very early adopters of both and the first company to use PHP with MongoDB. I hired a very capable engineering team including two of the core members of the Symphony team, Chris Wallsmith and John Wage. MongoDB was quite immature when we started development and we found plenty of bugs. Fortunately MongoDB's office was across 18th street in New York City and we frequently met with their engineers to work through issues. I still really didn't understand open source. I had created a handful of open source projects which never attracted a community of contributors or users. I had exactly one successful-ish open source project of my own which happened entirely by accident. This was my personal Vim configuration which I decided to put in a Git repo to make sure changes in one place replicated easily. I published it online in whatever we used for things like this before GitHub and since it was online people discovered it. Because it was well documented people started using it. Over time more and more people adopted it and today it's still one of the most popular Vim distributions. It was at OpenSky that Chris taught me my most valuable lesson in open source up to this point. Symphony had attracted some really talented people who volunteered their time on open source and I wanted to know how. I asked Chris how did he how did you get involved? He told me about when he went to a symphony conference to learn about it. Afterwards the creator of symphony Fabian was meeting with a few people about contributing. Fabian asked if anyone wanted to manage the release. Chris raised his hand. That was it. I couldn't believe it. It seemed like magic to get people to contribute all you had to do was ask. I also discovered it was possible to be employed to work on open source full time and not just as a hobby. I still didn't know how to go about it but John and Chris clearly did and I was a bit jealous. That's how I keep you wanting more. It was now 2011. I had four children and four less than successful startups under my belt. I decided to leave OpenSky and see if I could make working full time on open source a reality. I knew that MongoDB had transformed our development and I felt that it had the potential to fundamentally change how applications were going to be built forever. I met with the company leadership and they offered me a job. It had a salary but no title or role. I was very excited about the opportunity to work on open source full time but I was scared. I was throwing away my career. I took the offer in faith that everything would work out. Two weeks into the job I was feeling very out of place. Virtually everyone else there was a C++ programmer. They already had a manager of that team and I was glad it wasn't me. I spent time trying to get to know everyone and mostly that made everything worse. I had even less in common with them than I thought. More confused than anything I asked the founder, my boss, why he hired me. He told me that he hired me specifically because I was different from everyone else. I still felt out of place but at least I knew I had a purpose. I thought this might be too cheesy but people said no way the Drupal community is going to love it. As time passed I settled into the role of overseeing our user community, our drivers, our integration, our documentation. I was responsible for the user experience of MongoDB. The challenges we faced were overwhelming. At the time I joined we were the 40-something most popular database trying to overcome 40 years of inertia. This was easily the most established decision in technology. Nobody considered whether or not to use a relational database only which one. At the opposite side of the ring facing us was Oracle with their piles of cash and legions of salespeople and we had mugs. Not only were we trying to succeed in the space we're literally none had before but we were also trying to succeed as an open source company. To this point there was exactly one truly successful open source company and loads of unsuccessful ones. To make matters worse, the one success story Red Hat had taken a very different approach than we had as they were not the owners or creators of the software they sold. Questions kept going through my mind. Can we create a product that companies would be willing to pay for? Can we attract a significant user base? How would we distinguish our free from our paid offering? I felt overwhelmed and worried I wasn't up to the task. I knew that if we could create an experience that people loved then we would be successful. As a small startup the only way to do that was to go after developers and we did that by meeting developers where they already are. This meant finding places where developers were already building solutions with MongoDB and amplifying their efforts. It meant taking the good things that people had already built and trying to add on top of it instead of replacing it with our own built here solution. It also meant physically going to where our developers were and spending time with them. And too we needed to build delightfully idiomatic experiences collaboratively with our users. This meant trusting our users that they knew their language experience better than we did and we knew the database better than they did. Only together could we build something delightful. As part of this we decided to dog food everything as much as possible even if it was painful to do so. Any pain we experienced our users would have felt far more severely. My boss asked me to take over the responsibility of the website. Per our dog food policy we had already built our own CMS on top of MongoDB. It was functional but very hard to use for the marketing department. In all honesty it was hard for everyone to use. It also made no sense to create our own CMS. Our competency was in creating databases. What's worse it actually worked against our strategy of meeting developers where they were. We would be much better off taking an open source CMS and extending it to support MongoDB. Not only would we have a better CMS for our team to use but the CMS would gain functionality and scalability. After considering all the options there was only one viable one for us. Drupal. A quick search on Drupal.org turned up a plugin that someone had already written. It showed promise. I reached out to the author Chicks and decided to sponsor his development of the plugin and any related core work. I met with Chicks every week or so and we talked through his progress and worked through his challenges. We discussed that we would need to hire more people from the Drupal community to build out and maintain our site and Chicks suggested that I come to DrupalCon where I'd be able to meet him and the community. I thought it was a good idea and asked him when it was. He said it starts tomorrow. So I bought a plane ticket and I was on the next flight to Denver. Most weeks happen and you come out the other side a little closer to death but every once in a while every once in a while you have a week that changes your life. For my first DrupalCon was one of those weeks. I didn't know a single person in the Drupal community other than Chicks. I knew the name Drees but really nothing else. I met up with Chicks and he started introducing me to people. He introduced me to a bunch of people including Angie and the other core contributors. Later Chicks and I were discussing the entity field query design and he took me to another room and brought in David Strauss and the three of us whiteboarded out a solution. At the time I still had no idea that Chicks was a big deal in the Drupal community. I also had no idea that the people he was introducing me to were pretty much the inner circle of Drupal. What I did know was that DrupalCon was like nothing I'd ever seen before. I looked around and I was amazed at the excitement. I couldn't believe how many people there were. I couldn't believe the quality they'd put into the presentation of the conference from the banners to the stickers and decorations. I couldn't believe how many discussions were happening around architecture, strategy and culture. It might have just been the people I saw but it felt like everyone was part of something greater and felt responsible to make sure it was successful. That night I led above. The room was full of Drupalistas who wanted to talk about the opportunities MongoDB held. People were excited to hear that a module was in development and those who had used MongoDB in the past spoke about what advantages it offered. That night I went to bed exhausted with my brain spinning around what I just experienced. Nothing prepared me though for what happened next. I went to my first Drupal sprint day. I couldn't believe it. I still have a hard time believing it.  Hundreds of people self-organized into pods to work on some of Drupal's biggest issues. What's more they were including and mentoring new people in large amounts. This trip was already one of the most valuable experiences of my life and yet I still hadn't accomplished the very purpose I'd come for to find someone to hire to build out our MongoDB website. I scanned the room and I saw one person who was wearing a MongoDB shirt. It must be fate I thought. Nervously I walked up to the table where she was sitting at. We began talking and I learned she was working on her Drupal distribution for conferences. Codd. She had her own distribution so clearly she knew her Drupal stuff. I described to her the project for MongoDB and she seemed genuinely interested. I started asking her questions about specifics and she suggested we start working on the website theme right there. In turn I asked her if she wanted a job and she said yes and I hired her on the spot. That's a true story too. To date that's the only person I've ever hired on the spot. Over the next few years I would learn a lot from Emily. Not only was she a fantastically talented engineer but she was also a Drupal superfan. She embodied the values of the Drupal community and her contagious enthusiasm was exactly what I wanted to create for my projects. Once I had seen what a successful open source community could look like I could never forget it. Drupal had opened my eyes to what open source could become. A vibrant engaged community with distributed leadership all working together towards a single overarching goal. A community where people felt like they belonged so much that it was family for many of them. From that day forward I made it my goal to Drupalify. I don't even know if that's a word but it was my word. I was going to Drupalify any project I was part of. I'd also made it my goal to give back to Drupal as much as I felt like I had gained from it. I was waiting to see if people would get it. Very good. Inspired by Drupal I returned to New York City energized to build out a similar community. MongoDB's biggest challenges were we were a commercial company first and an open source project second. And our open source license was less friendly than others. AGPL. It's important to recognize that each open source project is unique. I was inspired by Drupal and the potential I saw for MongoDB. However I couldn't just copy what Drupal did as it wouldn't have had the same effect in our different situation. We quickly learned the developer community's form within programming languages. This meant that our community didn't really know each other at all. We had influencers in each language but no one knew anyone else. If we ever wanted a community like Drupal we needed to bring them together. Inspired by the Microsoft MVP program and the Google GDE program we built out a similar program which we called Mongo Masters. These were community leaders who had created drivers, applications, businesses, etc with MongoDB. They had caught the vision and they were excited to share it. I'd learned from Drupal the value of people coming together in person. I scheduled the time and flew everyone to Silicon Valley where we had a two-day Uncon-style summit. The main goal was just having people meet each other and realize there were people in other languages doing the same thing they were. It was a complete success and our community had started. Over the next three years the enthusiasm around MongoDB exploded. It was web scale after all. Oh, that died. That was complete dead. Maybe this was a video it made us very famous. Maybe you all missed it. It kind of went viral. I took advantage of the fact that we had exploded as much as possible. I focused on hiring the right people who were already passionately doing the work that we needed done. Since our user base was diverse and varied, spread across dozens of languages, both human and computer, I knew our team needed to be too. I built out a team of around 80 people, most of which I hired directly from the community, including people from Drupal. With developer engagement, an all-time high and a business plan that hinged on developer adoption, we went out to meet our developers where they were. We held MongoDB Day's conferences all over the world. In these we tried to emulate the community feel and developer-centered experience from DrupalCon as best we could. We also sponsored and spoke at many external conferences, including DrupalCon. The next three years is a bit of a blur. MongoDB had grown phenomenally. It surpassed our wildest dreams. It was now the fourth most popular database behind Oracle, Microsoft SQL and MySQL. Major companies had adopted it for critical projects and the company was highly profitable. The business could not have been in better shape. The community had gone through an evolution. MongoDB needed a strong community at the beginning to establish momentum and take on the enterprise market. Once MongoDB stabilized, there wasn't anything to keep the community leaders engaged. As our business grew, our community shrank. We went from a couple of conferences to over 25 in one year and now we were down to a single annual conference. The conference audience had shifted to the enterprise, indicative of MongoDB's next phase. I knew I was the right person to have led MongoDB for those first three years. I also knew I wasn't the right person to take it to the enterprise. Leaving MongoDB was one of the hardest things I had to do. My passion was in building the community and creating the user experience. I succeeded in doing both and built up an amazing team who felt like family. As the company shifted to focus entirely on enterprise, I knew it was time for me to find a new place for my passion. I stood in front of my whole team and cried as I told them I was leaving. I didn't know where I was going to go next, but for the first time, I knew what it felt like to be a part of a successful startup, one that disrupted the industry and I knew I wanted to do that again. Permit me to rewind the story a bit. As part of my role at MongoDB, I was responsible for determining what languages and frameworks we supported. I had experienced personally writing seven of the languages. I prided myself on being a polyglot and commonly did code reviews and co-wrote design docs in all the languages we supported. I also kept a close eye on emerging languages. One language in particular caught my eye. It was created at Google by a trio of language luminaries. We adopted Go as our 12th language and it didn't take me long to realize I didn't want to be a polyglot anymore. Go had spoken to me in a way that no language ever had. To me, it just made sense and write and go made programming fun again. I spent my free time immersed in learning and writing Go. I've never been the kind of person to learn only by reading books and besides, there weren't any books written in Go yet anyway. I decided I needed a project. By this point, I had switched my vlog over to WordPress and while I liked the simplicity of the authoring experience, there was a lot of things that bothered me. I was frustrated how expensive hosting it was. I couldn't stand how often I had to apply security updates. I actually calculated it. I spent more time doing security patches than I spent vlogging. I hated how inefficient my static content was dynamically rendered for each visit. I decided I would switch to a static site generator and try to handful out. There were things I liked about each of them, but I couldn't get over the fact that they were all so slow. Since I was going to learn Go, I needed a project and I figured Go had to be faster than Ruby or Python. So I would learn to write Go by writing a static site generator and Hugo was born on the 4th of July in 2013. The following year, a pair of community members founded Go4Com, the first Go conference in Denver. I presented at the conference on MongoDB and Go, along with Gustavo, the lead author of the MongoDB Go driver. I arrived there a day early and walked around to see what was going on. I found the organizers and some friends stuffing Goody bags. I jumped right in and helped them. The next day, the organizers were up on stage and struggling to MC while also coordinating everything. Another community member jumped up and offered to MC for them and did so masterfully. Over 700 Gofers came to that first Go4Com. Here was the fledgling community that had the potential to be my Drupal. Like Drupal, there was there were people who saw the need for something and they jumped right in and volunteered. In fact, it had a lot of the same characteristics. Brilliant founders, commitment to inclusion and diversity, a product that solved problems across a broad space, and it had enthusiasm, lots of it. I was one of only a handful of people who had experience leading a successful company based on an open source project. Go's breakout application, Docker, approached me to help them try to achieve the same kind of success. I thought this would be a great chance to immerse myself in the Go community and apply everything I learned at MongoDB. As it turned out, I could not have been more wrong. Other than being open source, MongoDB and Docker had almost nothing in common. MongoDB entirely controlled MongoDB, Inc. entirely controlled MongoDB. Docker, Inc. was wrestling for control over their own project against industry titans, including IBM, Google, and Red Hat. At MongoDB, we struggled to get external contributions. At Docker, our biggest issue was that our very small engineering team was overwhelmed with contributions. The problem was so bad that any engineering they did was on their free time. Their day job was consumed with reviewing patches sent by others. There was also a secondary problem that while we received many patches, mostly from large corporations, the number of active contributors was actually shrinking pretty rapidly. Once again, I found inspiration in Drupal. Drupal is one of a very small number of projects that has figured out the secret to distributed leadership and contributor scale. Decisions are made by a distributed group of individuals. Innovations happen on the fringe before eventual adoption into core. Contributors are mentored and grow into more significant roles over time. DrupalCon and DrupalCamps provide an ideal nurturing environment for people to join the project. There's not another open source project in history that has been able to do this at the scale Drupal has. Taking inspiration from Drupal, I initiated three major efforts. First, we held a contributor summit in person. In spite of working together for over a year, virtually no one had ever met anyone else in person. We picked the 50 or so most active contributors and had everyone gather in San Francisco for an in-person summit. I created and ran the Docker birthday party. This was an ambitious event with the purpose to leverage the excitement around Docker to reverse the trend of shrinking contributors. Our contributors were normal sized and they stayed that way, but the number of them shrunk. It was entirely designed to replicate the DrupalCon sprint experience. We couldn't attach it to DockerCon, which was mostly a sales adoption vehicle rather than a community event. Instead, we leveraged our meetup network and held 26 parties in cities all around the globe. We flew a Docker engineer to each location and they joined with local leaders to teach people go and help them make their first contribution to Docker. Recognizing that we are a commercial company as well as an open source project, I wanted to reinforce the contributions to the project benefited everyone. For every contribution we received, we would donate money to a Wildlife Preservation Association. If we received 250 contributions, that would be enough to adopt a whale who we named MaliDoc. We ended up with over a thousand attendees, over 75 new contributors, and we received hundreds of contributions and MaliDoc has been part of the family ever since. At Docker, we constantly struggled with our tooling due to the simple fact, I'll keep talking now, due to the simple fact that GitHub was built for small projects. Of the many issues, perhaps the biggest one was that there was no way to collaborate on a pull request. We could either merge it or reject it. It was rare that a patch was ready to merge, yet rejecting it would have a very negative impact on morale. We wish there was a way to collaborate. We ended up defining a new term called, which we called carrying a PR or pull request, which is when we merged and then fixed up the pull request. We also built a ton of tooling around GitHub which helped to mitigate some of the scale issues but never came close to the collaborative workflow that Drupal.org has achieved. I was only at Docker for about one year. There was constant friction between myself and the leadership. I knew the only way our company would succeed was to give up some of the control of the Docker container engine and pivot towards the orchestration piece. They were unwilling to budge and we finally came to an agreement. They would agree to do things the way they wanted and I would agree not to work there anymore. After I left Docker I was feeling burned out. I'd been at six startups before they were even called startups, since before they were even called startups and I'd barely taken a vacation.  A couple months passed and things had taken a turn for the worse. By Thanksgiving I knew something was very seriously wrong. I was diagnosed sorry I've never talked about this in public before. I was diagnosed with two life altering and potentially fatal illnesses, Pobesia and Bartonella. These illnesses affect your blood and consequently every part of your body that depends on blood. I also had three very successful projects that I had started. Hugo, Cobra and Viper. At the time Hugo was the fastest growing project in Go, powering hundreds of thousands of websites. I felt like I owed it to my contributors and my users that I should work on the project. The illness prevented me from doing so. It was very hard for me to admit that I was no longer able to work on the projects that I had started. Telling the Hugo team that I wasn't able to work on it anymore was one of the hardest things I had to do. I had to step aside and give the reins to relative strangers. Thankfully people stepped up and filled the void. In particular a saxophone player from Norway named Bjorn took over Hugo and Cobra. Altogether I spent a year out of work during which I experienced great fatigue and depression. I was broken in so many ways. My body was broken with illness and my spirit was feeling like I had no worth. The only way I got through it was thanks to the support and love of friends, many of whom I had made through open source. There were four people in particular who stood by me and cared about me even when they had nothing to gain from me. You're already starting to cry I can tell which means I'm going to start crying. It's not going to be good for any of us. So the first of these was Megan who stood up on the stage yesterday. She gave me perspective at a time when I needed it the most. There was Sarah Novotny who gave me courage and hope and she's my mentor today at Google. There's Ashley who gave me friendship and support and let me be her mentor. There's my wife Winter who gave me everything. I got napkins so I won't pull up my shirt and show you all my stomach. Winter gave me everything and stood by me the most when I was at my worst. With their help I was able to rediscover my worth. I can't do that so I put her up. It was like maybe I could but not after the previous four slides. Through this experience I learned something I hadn't been able to learn through my entire career. I learned that sometimes happiness means giving something you love away. I also learned that life doesn't always go according to plan.  I was very fortunate to have a number of companies interested and I narrowed it down to two large banks in Google. The banks offered me VP roles with very compelling packages including a nice salary, first class travel and even an expense account. I was very tempted to accept these offers yet I felt something missing from both of them. I'd gone through a rough patch and my friends in the open source community got me through it. The banks offered more money but I couldn't imagine life outside of the community. My heart was with go and that's where I needed to be. I took the role at Google and didn't look back. This was a big transition for me. I was used to running a large portion of the companies I'd been at. Additionally I was a co-organizer of two Go conferences and the creator of some of the most popular applications and libraries in Go. And I felt that I was pretty well known in the Go community. Let's just call it what it is. I thought it was a big deal. At Google I wasn't a big deal, like not even a little bit. I now found myself working alongside people who were truly big deals. I was starstruck and intimidated. I saw an older gentleman walking around the New York City office wearing a corn t-shirt. I thought it was kind of strange to see a person from that generation liking the metal band. My co-worker whispered to me, that's David Corn, the creator of the corn shell. One day at lunch we ate with Brian Kernigan, the co-creator of AUK. He's the K. He wrote The First Hello World. He's also the co-author of The Practice of Programming, among many, many other books. He also named UNIX. The Go team was especially intimidating. I had looked up to so many of them for as long as I could remember. I now sat next to PJW, one of the other creators of AUK. He's the W. And the manager of the team at Bell Labs, when C and UNIX were created. I was invited to a weekly meeting with Rob Pike, the creator of Plan 9. UNIX's successor. UTF-8 and Go. Robert Griezmeier, who is responsible for V8, which is the JavaScript runtime engine that powers Chrome and Node.js. He also is responsible for the Java virtual machine, Hotspot, and one of the co-creators of Go. Ken Thompson, who had created BC, UNIX, UTF-8 and Go, had retired by this point. It also had Russ Cox, the Go team lead, Ian Lance Taylor, one of the new compiler leads, without which we wouldn't have Linux, Apache, MySQL, or PHP. And finally, Brad Fitzpatrick, who created Memcache and LiveJournal. I don't think I said a word in that meeting for the first couple months, and often wondered why I was in that meeting at all. I was at Google for about four months, and Rob Pike asked me a question. Me. I couldn't believe it. In doing so, he also conveyed why I was in the meeting. I understood something that none of these luminaries did. I understood the Go community. From that point on, I focused on helping the Go project evolve to become more like Drupal, and often use Drupal as an example of what Go could become. So these slides, these next few slides are from an actual presentation that I gave to Go team. It's just a sample, because it's a sample, because it's a long keynote. Oh, no. It's good. So this slide here I used to demonstrate the shape of the Go project. If you notice, the Go project is, the Go team is in one place, and the community is in a completely different place. I called this open, but not inclusive. The next slide I modeled after Drupal. Although you have more circles, the shape is the same, where the Go has a small team for Google outside of the community, but the Go team itself is embedded inside the community. There's many sub-teams which have distributed leadership. I based this on Drupal as demonstrating what a scalable project could look like. Jumping forward a few months, things were going well with Go. We had just run our first ever contributor summit and our first contributor workshop, which both exceeded expectations. It was clear that other open source teams at Google were also struggling with the same sort of things. I partnered with the strategy lead of the Kubernetes team, and together we went on to draft the playbook for open source. As it started to take shape, we invited a handful of collaborators, including Angie, from the Drupal community to help us. This work is ongoing, and we are proud to have published the first section on opensource.google.com. While we were drafting this playbook, open source had a watershed moment, which caused us all to question our approaches to codes of conduct. This led us to seriously evaluate the effectiveness of all open source codes of conduct. We discovered that while most were well written in their declaration of values, most had no guidance on what to do when a conflict arose. Once again, Drupal was a leader in regard with its community working group and code of conduct. Looking at Drupal as inspiration, Google published our own code of conduct, which we based largely on the contributor covenant to unify all of Google's over 4,000 open source projects. Perhaps more importantly, we also published a universal conflict resolution policy, again inspired by Drupal, for all of Google's projects. In the year 2050, when we finally figured out flying cars and hoverboards, our grandkids or great-can kids, or who knows, our clones, may discover that we were part of Drupal in the year 2018, what will they ask us about? Will they be asking us about Drupal to CMS? Or will they be asking us about how Drupal enabled business? I believe, above all of these, they will be asking us how Drupal pioneered modern software. I could say open source, but in 2050, there will only be open source software, so they just call it software. So Drupal has taught the rest of us what open source could be. Of the many things Drupal pioneered, I want to focus on three of them. Distributed leadership. Drupal pioneered distributed leadership and stands alone as the most successful project to truly spread leadership out across the community. In Drupal, leadership is expected of everyone in the community. From the earliest days, Dries emphasized that this was a shared responsibility and welcomed leadership from everywhere. Drupal owes much of its longevity to the way that it has fostered and mentored new leaders. Two, collaborative development. The biggest lesson I learned from being in those weekly meetings was it's always worth the time to get it right. As they say, no is temporary, but yes lasts forever. This requires tools that encourage open and collaborative reviews, keeping a history of modifications to a proposed change and the ability to have others propose changes to a proposed change. My projects didn't have this prior to coming to Google. Drupal's had this for a long time thanks to Drupal.org. I love seeing how many revisions and proposals are made on a single issue inside Drupal. Drupal pioneered the idea that everyone should take part in the review process. This not only distributes the review load, but also mentors people on how to do better reviews. Most projects today are bottlenecked by only having maintainers review code. They consequently have no pipeline in place to alleviate the problem. Drupal set the standard for distributed collaborative development, a standard that is still unmatched today in open source. And third, community engagement. I know of no other project that has been able to match the spirit, friendliness, and inclusivity of the Drupal community. This is why the first Drupal con was so life-changing for me. I've never seen anything like this before. It is truly a family to so many of us. You care about each other as you work on the code, helping each other in issue cues or with sprint mentoring. What is even more important is that you support each other in life and create truly meaningful friendships. Without Drupal, the world of open source would be a very different place. So the road ahead, 2018 and beyond. Drupal now finds itself in the position where no project has ever been. No other community in open source has ever survived this long. And there's a reason for this. For 17 years, Drupal has pioneered open source. At each stage of Drupal's evolution, you have risen to the occasion and pushed the boundaries of what is possible. You saw the need and without any examples to follow, boldly went where no project has gone before. So my message to you today is don't stop.   Don't stop asking the hard questions. Don't stop innovating. And don't stop caring. I can't tell you what comes next. All I can tell you is we are watching. What you do matters. It matters to Drupal and it matters to open source. You are showing us all the way to go. Thank you. So we have time for a couple of questions. So I thought I would start with one about your journey, right? Early you mentioned that Zoup was technically ahead of its time, but it seems like your career success came when you incorporated those softer skills and really started to focus in on both strategic decision making, being involved in strategic decision making and people management. How did you build those skills? Honestly, a lot of those skills came when I was doing missionary work. The furthest thing away from a computer, where I was forced to actually only interact with people. And it also happened through college.  You know, and one of the things you didn't mention is that you've served on the Drupal Association Board for the last few years. And you know, bringing this kind of perspective, this outsider, insider perspective has been very valuable, but one of the most visible roles that you've had while you've been on the board was as a member of the Technical Advisory Board. And you were, many people, I don't know if you know this, but you were focused on modernizing those collaboration tools for Drupal.org. So I wondered if you could talk a little bit about what you see as the future for tooling on D.O. Sure. I think we're in an interesting place. I think, as I said in my talk, there are features on Drupal.org that are so invaluable and lacking in most other places. And we've met with GitHub and GitLab and others, and they don't even understand what those tools, why those tools are important, why those features are needed. But you understand why those features are needed because it's what powers this great project. I think what we need to do is figure out a way that we can modernize what we have and bring it forward just like we did years ago when we moved from subversion to Git. And if that means partnering with someone else, maybe it does. But we can't lose what makes us who we are and what really makes this run. And I think we're in an interesting time. Lots of different tools are emerging. I know Google has tools we use that are pretty similar to this. And they're also kind of clunky. But they give us what we need to for the review process. I think if you had one thing that you could recommend to everybody today in terms of how they can help Drupal kind of maintain its secret sauce, what would that be? Other than like the whole keynote? Well, yeah, the whole keynote, yeah, pretty much. Could you say that again? Don't stop. I really think that's it. I think keep trying, keep showing up. Everything in life goes through different cycles and there's ups and there's downs and every project goes through that. I was talking to a board member yesterday. I remember when JavaScript was a dirty word and nobody wanted to touch it. And now JavaScript rules the world. And so everything comes in cycles, continue to push, continue to go. And like I said, we're all watching you. Okay. Well, thank you very much.


Hello and welcome to this session. This is Professor Farhad in which we learn how to find the price of a bond. This topic is covered on the CPA, BEC section as well as well as the FAR section. It's also covered on the CFA exam. This topic on the CPA, it's a little bit tricky and the reason is simple. Because when you learn about bond pricing, you need to know about the time value of money. So this lecture is basically for students who are taken principles of investments or essential of investments, which is relatively speaking an advanced course. But if you don't know how to deal with the time value of money, you can go to farhatlectures.com or if you're looking to supplement your CPA preparation or your CFA preparation, please go to farhatlectures.com where I teach you all about this. Now, if you're taking a CPA exam, I don't replace your CPA exam. I cannot claim to do so. What I do is I supplement. My lectures will help you keep up with your CPA prep course. So I do have lectures about many topics. Please, if you like my lectures, please like them and share them. Connect with me on LinkedIn, subscribe to my YouTube. I have 1,800 plus lectures. Also, you could connect with me on Instagram and Facebook. And again, on my website farhatlectures.com, you'll find additional resources for this course as well as other courses. So let's talk about a bond and how does a bond work? Well, let's do a quick review about a bond. What is a bond? Basically, a bond is when the company borrows money and they give you a bond. So simply put, we have a company here. The company needs money. They will go to the market and we have lenders or investors and the company will give them the bond. The lenders will give the company back the money that they need. Then the company will pay them interests with pay interest to the lenders. So what does a bond looks like? So this is what the bond would look like. The bond will have a face value or par value, something called face or par value. And I'm going to keep it very simple. I'm going to assume the company needs to borrow $1,000, which is one bond. The bond face value or par value is the amount that the company will have to pay back. So the lender will give them the money. Now the company will have to pay back the face value. The face value is also called the maturity value because when it matured, when the bond mature, you have to pay back this $1,000. Now within the bond, you have what's called the stated rate, stated rate or another word for it or coupon rate goes by other terms, but we're going to go stated rate or coupon rate. What does that mean? It's a rate. It's a percentage. For example, here it's 8%. It means this bond would pay interest 8%. Now the interest on the bond is paid semi-annually. What does that mean? It means each six months, they will pay you 4%. So to find out how much you get paid off this bond, you will take $1,000 times 4%. You will get paid $40 every six months. For two annual, you'll get the $80. Now let's assume this bond has a life of three years. If this bond has a life of three years, it means it's going to have one, two, three, it's going to have six payments. And this is what we mean by the payments. So it's going to be $40, $40 for year one, $40, and $40 for year two, $40, then $40. So it's going to make six payments of $40. Each six months, they'll pay you $60. So what happens is every six months, the holder of this bond, they will clip the coupon and they will take it to the company, think about it that way, and the company will give them $40. Once all these coupons are gone, which is three years later after they redeem all the coupons, they will go back and get the face value of the bond. Now that's very important to understand this picture because this is what's happening when you buy a bond. Why is this important? Because when you want to price a bond, you have to understand what you are buying in the first place. So when you invest in a bond, you are buying two things. Notice when you invest in a bond, you are buying two things.  What does that mean? It means you're going to be giving money today and you're going to get back $1,000 and throughout the life of the bond, you're going to be getting the payments. So to find the price of the bond, what you are really doing is you're finding the present value of the coupons. Here are the coupons, $40. So you have the coupons, $40 times the present value. Well, let's think about it. The coupons are the same, $40, $40, $40, $40, $40 and $40. We call this an annuity. So basically you are looking at the present value of an annuity. Now every, well, we know this present value, the period equal to six, you're getting six payments. The question is which interest rate do you use for this annuity? In other words, when you discount, you have to use interest rate. We have to be very careful here. When you discount, you have to use what's called the market rate or the yield. Well, this is going to be giving. So I'm going to put this on the side. Just kind of to remind you, this is something different. The market rate or the required rate of return. So when you, when the investor is trying to buy a bond, they will need to find the present value of the coupon payments first. When they find the present value, which interest rate do they use? They don't use this stated rate, unless the market rate is eight. And for the sake of illustration, I'm going to assume the market rate is eight. So here I'm going to assume the market rate is eight and the coupon rate is eight, just for the sake of illustration. But the market rate doesn't have to be as the coupon rate. And oftentimes it's not. And I will explain the implication of that shortly. Therefore, the market rate is eight. You have to multiply it by half a percent. I'm not half a percent by one half because the bond pays interest semi-annually. Therefore, the interest rate is four percent. So what you do is you find the present value of the inwardly. That's one part of the bond. This is part two of the bond right here. So we did this. Then you have to find the present value of the par value. What's the par value plus the par value equal a thousand. But remember, the par value, you're going to get it only once. So also you're going to find, you're going to multiply the thousand dollar by the present value of one. The present value of one, it means you're going to be getting this money only once and equal to six. Whatever you use for the annuity, you would use for the present value for the phase value and I equal to four percent. So this is basically the big picture. Don't worry, we're going to work an actual example to win this. But this is basically what you do when you buy a bond. The bond is composed of two components. The phase value is component number one. You will discount the phase value based of all the discount thing happened based on the market rate. And for now, I'm using eight percent for both the bond and the market rate, which it doesn't have to be. And often it's not then the present value of the coupon payment. So let's take a look at another formula saying the same thing, basically the price of the bond, the bond value equal to the sum of the coupon payments divided by one plus R, the interest rate raised to the end, which is the present value of the coupon payment of the annuity plus discounting the phase value. Same thing as this formula or the price of the bond equal to the coupon times the annuity factor. This is what I put down plus the power value times the present value annuity factor of the power value. Basically saying the same thing. Now the best way is to show you an example. Now we're going to work on Excel. Let's assume we are dealing with a bond that pays eight percent. It's a 30 year bond with a phase value of a thousand. This bond is making 60 semi-annual payments because it's 30 years. It's being twice a year. Therefore it's 60. The $40 is a thousand times eight percent. Well, 80 divided by two equal to $40. So we're going to be making the payment. So here's what we do and don't worry. We're going to work the computation in a moment. We're going to find the present value of the sum of all the payments discounted plus the thousand dollar discounted. And what we find out when we do so, because we're using eight percent as a discount rate and the coupon rate is eight percent, we're going to get exactly the phase value. Now we're going to see why later on you will not get the phase value. So it's easy to confirm that the present value of the bond, 60 semi-annual payment of $40. So the payments present value of the annuity is 904.94 and the present value of the thousand dollar payment 30 years from now is $95.06, which in total will give you, this is the present value of the par value. Together they will give you a value of a thousand dollar. Now you could use a financial calculator to find this, to find the prices and a financial calculator when the annual market interest rate, again we're assuming annual market interest rate at age is to make this simple. So you'll put the information in the following order. First you put in the number of periods and you'll put the number 60. And why it's 60? Because the bond had 30 years, 30 years times two payments a year. Then you have I, you put I the interest rate equal to four percent. Remember the market rate is eight percent since the payments are semi-annual. You have to adjust your interest rate. Then you put the future value is a thousand dollar. The bond will provide one time cash flow of a thousand dollar when it mature. Then the payment, you click on PMT, the payment is $40. And I come, how do you come up with the payment? It's one thousand dollar times eight percent, the coupon rate. And I emphasize here the coupon rate. Don't confuse this eight percent with this eight percent. This eight percent is for the market rate, not for the coupon rate. Now on most calculator, you would, you would punch the word compute or COMP or CPT and then enter PV to obtain the bond price. Now what's going to happen? The PV, it's going to, going to show as a negative one thousand because you have to pay a thousand dollar to make the investment. So the negative sign signifies that while the investor receive cash flow from the bond, the price to pay the bond as a cash outflow or a negative cash flow. Think about it. When you start your education, when you start to make investment in your career, you have to pay. It's a negative outflow. That's why the calculator will show you, will show you the number as a negative because it's the price of the bond that you have to pay today. It's a negative outflow. Corporate bonds typically issued at par. What does that mean? Now, I would not agree with the statement, but let's assume the issue at par. At par mean, let's assume the company wants to borrow a thousand dollar, the face value, they will get a thousand dollar for that. But often that's not the case. This means that the underwriter of the bond, of the bond issue, must choose a coupon rate very closely approximate market yield. It's the market rate. Remember, if the bond, remember, we have the bond coupon rate, coupon rate, let's do this now. It's a good, it's a good idea. We have the bond coupon rate and we have the market rate or the market yield. And here's what's going to happen. Let's assume the company is offering 8% and the market rate is 8%. What does that mean? It means this company is telling the investors, I'm willing to pay you 8% if you invest $1,000 with me. These investors, they are not dummy. They're going to go to the market and find out what is the market rate for similar bonds. If the market rate for similar bond is 8%, we would say that the bond will sell at par value. Par value means that the company will get exactly the par value for their bond. It means if the par value is $1,000, they will get $1,000. Now, let's assume the company is offering 8%, the market is offering 10%. Now, why would we offer 8% and not 10% like the market? Because we cannot afford the paying 10% cash outflow, just we can't. We can only offer 8%.  I'm not going to pay you the full $1,000. I can take my money somewhere else to the market and earn 10%. So what happened is under those circumstances, your bond will sell at a discount. What does that mean? It means rather than getting $1,000, the company will sell the bond for $930. I just made up this number, something less than 1,000. Let's assume the company is offering 8% and the market is offering 6%. What happened under those circumstances? Well, everyone's going to look at the market, then look at your bond. They're going to say, wow, this company is offering more than the market. What happened under those circumstances? Your bond will sell at a premium. What does that mean? It means rather than getting the $1,000, the company will get $1,050. I'm just making this number up more than 1,000. Okay. So of the rate, if the coupon rate is an adequate, investors will not pay the power value for the bond. What does it mean? They don't pay the power value. It means they pay something less than the power value. Well, if the coupon rate is more than adequate, then they will pay more than the power value, which is they pay a premium. Okay. After the bond are issued, bondholders may buy or sell the bonds in the secondary market that has nothing to do with the company. Once the bond is selling in the secondary market, the company is out of this. Okay. Now we have to understand in the bond market, in the bond market, the main determinant of bond prices is market interest rate. Again, back to the same concept that I just told you. If you have a bond, let's assume you have a bond that's paying 8% and suddenly market rate, the market rate over all the market rate, the Federal Reserve reduced the interest rate and the market rate went down to 5%. Now anyone that's selling bonds, they only have to offer 5% and your bond already pays 8%. So if you carry this bond, your bond will sell at a premium or the bond price will go up. So notice as interest rate went down, fluctuate inversely as interest rate as interest rate over all interest rate goes down, your bond value will go up. And let's switch the scenario. You're offering a bond paying 8% and now the market rate, the Federal Reserve increased the market, the interest rate and now the rate is 12%.  Now investors can go to the market and buy a similar bond paying 12%. What's going to happen is now interest rate went up, your bond value will go down and don't worry, we're going to see this in numbers in a second, but this is the idea. So this is a central feature, not only for bond for any fixed income security. So when we're dealing with fixed income, what fluctuate the fixed income is the ongoing interest rate and let's take a look at these figures and an Excel sheet to see how this all fits together. Let's assume we are looking at this bond. This bond is paying 8%, annually, semi annually is 4%. The face value for this bond is $1,000, just one bond, number of years is 30, number of payment is 60, which as we already know this and coupon payment is $40, which is the face value times 4% or the face value times 8% divided by 2. So this is the 8% and the market rate semi-annually is 8%, so the market rate is 8 and the market rate semi-annually is 4%. So notice we're looking at two different things. This 8% here that I highlight in red, this 8% is what the company is offering. This 8% is printed on the bond, stated on the bond, it's what the company is offering. This market rate semi-annual that I have it in yellow, this is what the ongoing market, what similar companies are selling for, 8%. They happen to be the same. So let's find, using the Excel sheet, the present value or the bond price. Here's what's going to happen. Well, before I do so, I should know that my price should be 1000 because if the company is offering 8 and the market is 8, it should sell exactly at 1000, at par value. So here's what's going to happen. First, I'm going to find the present value of the annuity. What's the present value of the annuity? First, you have to put the rate. The rate is MB10, always you would use the market rate. So notice the rate is cell B10. Cell B10 is the semi-annual interest rate of 4%, then comma B6. What's B6? The number of payments. Okay, number of payments, number of payments right here. Then comma B8. B8 is the coupon payment of $40. When I find the present value and notice I put negative here because if I don't put the negative, the answer will be minus. So I put the negative, so the answer is plus. So when I find the present value of the $40, so the present value of the $40 alone is $904.94. Let me do it, let me show it to you one more time, like what we did it earlier. So what I said earlier when we started the session, I said the price of the bond is the present value of the annuity. So the annuity here is $40 and the present value of this annuity equal to $904.94. So simply put, you're going to be receiving, let me show it to you on a timeline. You're going to be receiving, let's assume those dashes, we have total of 60 dashes and each dash represent a payment of $40. When I discount, when I find the present value of all these dashes, they equal to $904.94. Now, I'm going to have to find the present value of the face value, the face value is 1000. How do I find the present value? I'll take 1000 and I'll take the face value divided by one plus the interest rate B10 raised to the 60th power raised to N. So notice it's the formula is the face value divided by one plus I, the market rate raised to the Nth power. Okay. And if I do so, I will find out that $1,000 is worth $95.06. So I'm going to be receiving $1,000 30 years from now. If I discount that $1,000 till today, it's worth by itself $95.06. So it's very important to see the bond as two different pieces. One is the present value of the annuity. The other one is the present value of the face payment. Now, what I'm going to do is this, I'm going to show you what's going to happen to this bond, if we, if the market rate changes. So let's assume I'm going to change the market rate from, let's make this a premium bond. Premium. So let's assume the market is paying, the market is paying 6%. If the market is paying 6% and I'm paying eight, notice what happened. The present value of the payments are worth $1,107.02 and the present value of the face value is worth $169.00. Together they're equal to $1,276.00. Notice the bond sells at a premium. Why does it sell at a premium? Because the ongoing rate is lower than what the company is offering. So I'm going to keep the coupon rate fixed. Let me show you how you come up with a discount bond. If the company is paying 6%, but the market rate is 10%. 10% means 5% semi-annually. If I discount my payment using 5%, the payments alone are worth $7.57.17 and the face value is worth $53.54. Notice my bond is selling at a discount because my rate is not competitive now. Now once again, you can go ahead. Let's change this to 2%. Well, if I change this to 2%, if the market is paying 2% and your company is offering 8%, everybody's going to run to your bond and wants to buy your bond, your band will sell at $2,348.00 at a really, really high premium. Also, if the market is offering crazy 20% per year and your company is offering 8%, I'm just showing you extreme examples so you see the point, well, your bond will sell at a discount and you would only be able to get $401.00 for your bond. And this is the same thing. So when you buy a bond, so the key point here is to understand when the investor buys a bond, the investor look at two things. They would look at the future payment, which called the annuity, and they will discount the annuity using the market rate. I'm going to put here the market rate. Then they would look at how much they're going to get in the face value. They will take the face value and they will discount it using the market rate. Now I'm showing you this as a simple example, but the concept is the same. Even if you buy a bond three years later or four years later, how do you find what's the bond? What's how much is the bond is worth? Well, you would look at how much payments am I going to be getting into the future? You discount them. You'll find what's the face value that I'm going to be getting in the future. I will discount that face value. Those two numbers together will be the bond price. Once again, if the coupon rate is higher than the ongoing rate, your bond should, should sell at a pretty, you should sell at a premium. If it's lower, it should sell at a discount. If it's exactly the same rate, it should sell at par. So this is all what I'm going to do in this session. We're going to be working in the next session. I'm going to look at the bond yield because that's very important to understand this concept. What is the bond yield? Always, I'm going to remind you to like my lecture, share it. If it benefits you, it means it might benefit other people and then don't forget to visit farhatlectures.com for additional resources for this course, as well as other courses. If you're studying for your CPA exam, this is your chance to have some additional resources to help you pass the exam. Good luck and study hard.


I'm Christian Glombeck. I'm one of the co-chairs for the OKD Working Group. And yeah, we'll be presenting on the state of OKD4 today. So welcome, everybody. Let's have a look at the agenda first. So we'll go through what is OKD4, then what is Fedora Core OS. We'll have a OKD4 beta demo, then we'll have a quick look at the road ahead. Then an introduction to the OKD Working Group, and then just a call to try the OKD4 beta. Let's get started. What is OKD4? OKD4 is the origin community distribution of Kubernetes. It is the OpenShift code base that is also used for the OpenShift Compute platform, our product at Red Hat, also called OCP, plus Fedora Core OS. You can find all the info on OKD.io. So OKD4, a community distribution of Kubernetes plus plus, it's automated installation, patching, and updates from the OS app. What does that mean? So we actually have bundled the operating system with the cluster, and it's all packaged together. So from the lowest level to the application level, it's all automated operations. We have the Linux host with Fedora Core OS platform and cluster management, which is the OpenShift Kubernetes distribution. And then on top of that, we have operators that run the applications in an automated manner. So let's see what platforms we support. We run on bare metal VMs, OpenStack, AWS, Microsoft Azure, and Google Cloud Platforms. For some of those platforms, you may need to upload the images manually before you can start the installation process, which requires a little bit of manual work. But most of it is really driven by the installer and fully automated on most platforms as well. OK, going to the next section. What is Fedora Core OS? Fedora Core OS is an automatically updating Linux OS. It's aimed at containerized workloads. It's based on RPM OS tree and ignition. And it's built with Core OS assembler and composed of Fedora RPM packages. So let's pause here a little bit. That's a lot of information on one slide. We have taken the best learnings from the atomic host OS and from Core OS, which is the technology's RPM OS tree and ignition, and put them together in Fedora Core OS, and also in Red Hat Core OS, which replaces Fedora Core OS in OCP. In OCP, we have Red Hat Core OS, or Red Hat Enterprise Linux Core OS instead of Fedora Core OS, which is the main difference between OKD and OCP. They're built with a tool called Core OS assembler. You can actually build your own operating system out of RPMs with that. And ignition is used to do the first boot configuration here. So I really like the concept. It's super easy to provide the configuration upfront, and then ignition takes care of configuring everything on first boot. And RPM OS tree is our immutable host OS, or the system that builds immutable host images. So it's an image-based operating system. All right. I'll hand this off to Vadim now for the OKD4 beta demo. So Vadim, take it away. Hello. My name is Vadim Murkowski, and I will demo OKD4 today. So if you're familiar with OpenShift Container Platform, our web console, you will notice that OKD4 landing page, overview page, is very similar to OCP, except we use different branding. It will come to down. We use different branding for OKD. And other than that, we support all the features which OKD has, meaning monitoring, inventory, cluster inventory, and details pages and all like that. The most major difference is that we use Fedora Core OS as a basis for all our nodes. Thus, we use a newer kernel version and the newer packages, including Cryer on Time and so on. In OKD4, we also support community operators using Operator Hub. So users won't have to require a subscription from Red Hat to install operators. In fact, in order to install OKD4, they don't require any full secret at all. And OKD4 also has a developer view, same as OCP, where developers get away from complexity of bots, deployments, and so on, and work with a simplified version and better focus on deploying the code instead of working with Kubernetes Previews. We also talked a lot about operators. So OKD4 contains approximately 30 operators right now, which make it run. And in order to demonstrate their value, we have created a small game, which is similar to standard duck hunt. But every time I shoot the duck, we're killing a pod or removing a deployment. Yeah, that's enough. And we can see that those pods, and if I kill, but our cluster doesn't go down, because the operators are ensuring that all the necessary pods are being restarted and we create the wrong scratch if necessary. So the game shows the value of the operators. And that's pretty much all I've got. All right, thank you very much Vadim. Let's continue with your road ahead. So we have a roadmap for OKD4. And with the beta release, we're really in the middle of phase one, which is we have something that works and we're still stabilizing it. And phase two would be reached when we have a GA release ready, which is soon, hopefully. And we'll be focusing on community collaboration and technology incubation in phase two and in the future. So what we really want to do is invite the community to participate in an OpenShift development and have a feedback circle that we, as Reted, also get value from and that we fix issues on the newer Fedora CoreOS system, newer with the meaning of it has the newest kernel and things like C Groups V2 and everything that hasn't landed in Reted CoreOS, Reted Enterprise Linux CoreOS yet. So we really want to use OKD as a vehicle to stabilize things before they land in our product and also give the community the opportunity to use these things early on. So technology incubation is a huge part in collaboration with the community. There's also great projects like the OpenShift ACME controller that can be used to provision certificates for services and routes that run in OpenShift. And we want to put these kinds of things in OKD or make them optionally installable in OKD so the community really gets value out of this. So yeah, this is the road ahead. Let's go to the OKD working group. The OKD working group is the place where we meet and discuss openly the development and future plans for OKD. We have a Slack channel, OpenShift Dev on the kubernetes.slack.com. We also have an OpenShift Commons Slack where you can find us in the general channel and also in the OKD for channel. We have a Google group, which you can find under that link. That's also used as our mailing list, so you can subscribe to that group and you'll get invitations to the bi-weekly video conference meetings, for example, which you can also, which we hold and you can find a calendar where those are marked on the Fedora, FedoCal under the link below. We also have two repositories. One is the github.com OpenShift slash community repository, which we use to track things we want to discuss in the meetings. And we have the OpenShift slash OKD repository, which is our tracker for our bug tracker, essentially. So with that, I would like to call on everybody to try the OKD for beta. You can find it on OKD.io slash download.html. And there's a few more resources linked here. The docs.okd.io, then we have our release viewer where you can see all the builds from our CI system and even try out newer unreleased versions. And again, those two repositories. So with that, I would like to say thank you for listening in and I hope you're enjoying working with OKD.