 Good morning. Thank you for coming. My name is Mark Eacy. I work for WinRiver. And there at WinRiver, I'm responsible for managing open source, both the inbound software that ends up in our products, as well as helping people contribute out and making sure all that software is good and clean. And I have a third responsibility. It's to look for different ROI opportunities around the open source model. Like, how can we benefit beyond those other two? And today, I'm going to talk about the third one. I'm going to talk about particularly, how can we benefit as a company from leveraging the open development model that's been so popular in the open source movement inside our company? Okay? No one really argues with the success of open source software. It's not a one-trick pony. And at one time, people probably remember, corporations would actually shun the allowing of open source in their corporations. But today, if you ignore it, you're at a big disadvantage. So the question is, you know, Linux is probably one of the greatest successes of all, but there are so many others, there's got to be something there, right, that we could tap into. And I found the quote from The Little Prince pretty relevant is to contrasting what we currently do inside our companies, meaning following a more traditional development model such as Agile, where he talks about you're given certain requirements, told to work on a certain schedule and get it out the door by a certain time. But I think the second half of the quote really captures the essence of the open development model, which we're going to talk about and return to as we go. Okay? So what were the goals? Like, why did we want to do this? We had clear objectives for success. And first and foremost, we wanted to increase the amount of innovation that was happening. Outside the more traditional, you know, product roadmap, people are given their requirements, they have to focus, they have to get those out the door. A lot of good stuff does get innovated along the way, but we believe that there are a lot of good ideas that people have. They had no way of expressing them or getting them out there into the minds of others in the company. Naturally, everybody wants to be able to share code more. And this whole idea that, you know, product groups largely form around silos, whether they're within a certain department or across departments. To me, silos are natural. I'm not here to say we should break them down. I know a lot of people talk about the inner source. This is very similar to the basic idea that the inner source movement is following. I think it's a good initiative. But they talk about breaking silos. I think we just have to make things happen between silos more smoothly. Okay? There's also a lot of duplicate work that happens. A lot of, you know, teams will develop the same thing, not knowing what the other team is doing. We had a similar experience with encryption detection for export. We had this need to determine whether there were certain encryption, you know, pieces in our code, especially when we bring in all this open source, and you didn't write that code. So people started writing this tool in each of their own groups to detect cryptography so they can fill out their export disclosures better. And the reality was we had four or five different groups writing the same tool. Wouldn't it be better if they all collaborated on one tool? Code preservation is such an important thing. We have situations where someone wrote a really useful tool. They were maintaining it, kind of, sort of. And then they left the company. It's somewhere on their laptop. Who knows what happened to the laptop? We have internal code hackathons to promote, you know, development of certain technologies. And in the past, a lot of great things were done in those hackathons, but that code is lost, right? So wouldn't it be great just to have a place to park all that stuff? You know, another obvious one. Trying to jumpstart an ecosystem outside, right? You're trying to encourage developers to develop stuff beyond their traditional, you know, requirements. And for example, Zephyr, which is now being sponsored by the Lenox Foundation, originally started as source code on our shelves at Wind River. And also VxWorks, which is a 30-year-old operating system, we are actually finding great ways to continue to promote it through, you know, people doing little initiatives inside the company and then open-sourcing them. And finally, and I think one of the most important things is to foster better employee retention. A lot of younger developers coming out of college are really used to participating in this open world. You know, they're all having code on GitHub and they want to have this opportunity to do this inside their company as well. So we think that generally people are happier and more productive for it. So those are the objectives. That's why we're trying to do it. Now the question was, you know, how do you do this successfully? And we had to answer three questions in order for this, we believe in order to understand it better, to implement it better. And the first one is, why does this open model work so well? And then, you know, what can we do to harness it inside internally? And finally, how can one participate? So I think it's really important to stop and reflect, right, and say, why does this thing, this open approach work? And the open source movement is not the first time. In fact, it's been done for centuries in academia and Newton is famously known for saying that he saw farther because he stood on the shoulders of others. Another great example is Wikipedia. Again, a non-software thing, in a sense. And what we have there is Microsoft came out within Cardia back in 1993 with a strong mission to succeed to digitalize the encyclopedia and they started out by putting it on CDs and then eventually moved it to the internet and the web. And they invested hundreds of millions of dollars into this. They were very committed to making this successful. Only to have about eight years later, Wikipedia get started as a grassroots initiative in a very open way with very little funding to take over and conquer that and Microsoft gave up on Cardia. Again, the power of open is pretty amazing. We don't even really have to discuss Lennox. Just look at Android, another perfect example. They started two years later than the iPhone and today they have 80, roughly 83% of the market because of the open approach they took. And then blogs. YouTube is another amazing thing. Very much, again, an open platform. I remember recently having gone to the car dealer to, you know, they said you had to replace your air filters. They said it's going to cost you $300. And I asked why and they started going through this whole thing why we have to open up everything, blah, blah, blah. I wasn't buying it. I went home, went on YouTube, searched very quickly, found out you can replace these two air filters in under 10 minutes. That's two air filters. And I went online, bought them for $20 a pop. I was done in $40 plus 10 minutes of my time. Again, the main point though is why did someone go out and publish this knowledge on the web using YouTube? And finally it is also, you know, open hardware. So what are the three key ingredients all these open movements have in common is the question we've had to answer. Content transparency is obvious. Like you just have to make the content out there and available for others. Don't block it up and make it hard to get to. Intrinsic motivators is the second one which is really critical to understand what motivates people to go to work every day for a company only to go at night and be more passionate, more committed to work for something for free. We're going to talk about those. Then there's technical enablement which you have to have the right enablement in order for things to work smoothly. So these are necessary and perhaps sufficient. Let's go. We won't talk about content transparency because I think it's kind of an obvious one. But I think the human intrinsic motivators is critical. So Daniel Pink wrote a book, Drive, it's a New York Times bestseller, and he talks about human motivators and what's new today. And he talked about three things. Autonomy. People are highly motivated when they have a lot of autonomy over choosing. Not just what to work on but when to work on it, how long to work on it. For example, Wikipedia. People get to choose what topics to write about, when to write about it, and how far they want to go. Mastery. People want to become masters of things they work on. It could be professional, it could be personal, it could be a hobby. But people like to demonstrate their mastery to others as well. Wikipedia, again. People get to talk or pick a topic that they find particularly interesting and go out and demonstrate their expertise or their mastery of that topic to others. Lennox development is no different. And purpose. People want to participate on things that are purposeful and there's varying degrees of that. Obviously, participating on the Lennox kernel is very purposeful, very cool and very meaningful. But again, Wikipedia, trying to contribute content and being accepted into Wikipedia is something that you feel good about what you're doing for the reasons you're doing it. And if you capture these three intrinsic motivators, people will do incredible things and you might not even have to pay them. So every single open initiative that you looked at, that we looked at, all share these things. Whether it was in academia, to Wikipedia, to the Lennox kernel. Technical enablement. It's kind of an obvious one, but let's try to understand it a little more. So the Atlantic publication in the US in 2013 surveyed a number of top entrepreneurs, historians, technologists, and asked what was the most influential innovation humankind since fire? They wanted to rule out the wheel. And they asked each of these people to list out top 50, make their top 50 list. And then they brought all these lists together. They consolidated it. They wanted to see what was the most common. They came up with the top 25, based on everybody's 50. And here's the top 10 of that 25 list. And I think there's two of them in this list that are particularly relevant to understanding the open movement. So steam engine is obviously very important. No one's going to argue with the internet, vaccinations, the combustible engine. Paper made it to number six. And there's something particularly important about paper because that was the first time we were able to record and pass on knowledge. That was a point where we accelerated innovation. Not only is it a great innovation, but it accelerated innovation. And that's critical. Okay. Moving along, we have optical lenses. I'm very appreciative of those. Semiconductor. Again, we're all here because of that. Penicillin. Probably many people live today or exist today because of penicillin. Electricity is no brainer. But the number one, they came up with a printing press. And that was the other time in history. Not only was it a great invention, but it further accelerated innovation. It's not even, you know, so the sharing of knowledge allowed things to happen in a much greater way and in a more open way. And the natural progression to that is the internet, okay? So what we really want to take away from here is we have to make sure that we have technical enablement that kind of captures the essence of what these guys do. All right. So what are the, you know, these are three obvious, you know, things I believe are critical to the open source movement and why it succeeded. And we had to make sure we understood these, make sure we had them inside our company. The web and internet. Code repositories. Again, sharing like paper or the printing press. You allow things to spread further. And then finally, the license actually, a little more subtle one, but you want to remove friction and allow things to move and flow across, you know, different organizations. You needed a way to remove the intellectual property issue. And I've always highlighted this fact. If you have no license, we didn't have the open source license. There would be no movement. It would come to a screeching halt. I like to highlight that success that Android had in getting into the market. I believe one of their key components was the choice of the Apache license because it allowed a lot more hardware vendors to participate more readily to get that kind of momentum. So these are critical to any open source initiative. Okay. So in summary, what we have are three things that we have to make sure we accommodate inside our company in putting together a program. So in some sense, I've kind of addressed that first question. What were some of the key components that made the open movement successful? The question is, what can we do now inside to harness that? So we come up with what we call the code swap initiative. It's really, you know, not surprising, an internal open foundation if you want to call it that, just a program where people can participate inside the company to contribute code to be shared among others inside the company. One of the most important things I had to focus on was keeping it simple and making it simple. There's a lot of work to doing that. But also, you know, we identified three simple, what I would call core minimum viable technologies that have to be there. You can have others, but I think if as long as you have these three, you can start a grassroots initiative to get people to start sharing. As far as supporting those intrinsic motivators, first of all, I made it very clear that we shouldn't have any corporate mandate. No one should be required to participate in code swap. I think you go counter to the whole purpose of the open movement. We needed to have a way for our peers within the company to recognize other people when good things were done. And a third thing was very important was to have a pathway for some of those things that we develop inside the company to end up as open source software, okay? Because that's a natural progression for certain things and people always want to understand that. They want to contribute inside, but everybody really, really likes that idea of participating in the open world. And finally, something that I always like to emphasize and it's often overlooked, if you want any initiative to be successful, I always identify what I call the three E's. First of all, you need to enable. You need the infrastructure, right? You need to educate. And those are obvious. People often go out with a big presentation saying, all right, we're now doing this big initiative. But probably as important, if not the most important, is evangelism. You have to constantly and constantly remind people about the availability and how great it is. And here's the kind of recognition you have. If you miss out on that third one, you're probably not going to succeed at this, okay? So we have an internal, we talked about internal website. Of course we have GitHub, but it was also important to have a nice landing page. So what we have here is the page. I have to launch it. This is the actual page inside our company. And what we do is we feature different products or projects that are going on. Somebody wrote a whole nice library of useful scripts. FooStar is an interesting one. This is actually each project that gets momentum. We give them their own webpage, okay? FooStar is an internet smart connected foosball table. And basically they get some photos up there. This actually ended up in the Maker booth at the Maker conference for Intel. And it also ended up at a number of our trade shows. So this is one example where someone came along. They wanted to do this internet enabled foosball table and then ended up in a conference. Another one is we're about to open source. This is called, oops, let me see, the Lem Lander. This is the old traditional Lem Lander game where you can actually control the lunar module landing on the moon surface using controls. And it was built largely as an IoT demo for the trade shows. Another project that we have was this encryption script that detects encryption and code. And it actually was shared in this way and we promoted it and we were able to get a lot of people to contribute. But again, giving people that opportunity to have that kind of visibility is important. One of the things I also wanted to make sure was all the code was properly marked. Now, it wasn't so much, you know, to make sure we say it's when we're a property but also to give recognition to developers. I think that's part of that pure recognition part. What we do is if a project is actually chosen to be open source, we have a script that goes through and replaces these all with open source notices. But I think this is a really important component of giving them the recognition, especially when we open source something and during the performance evaluation time, we can talk to that. I mentioned a little earlier a part of this program, it was important for us to have what we call pathways to possible open sourcing what you develop internally. Not everything that we have developed internally as an open initiative is going to make it out to the open source world, but we want to make sure we get things out there that make sense. So we have these three pathways and the first one really simply says, on the first one, if you're working on something and a lot of companies have this, right, you want to make sure that if it doesn't create a conflict with the business that they feel comfortable working on it without getting into trouble so they can fill out a form and then the managers can approve it and then they can go on and work on that. The second thing is we're largely talking about code swap where they get to contribute code and if they're thinking about open sourcing something, they have to start there, go put it into the code swap repository. And thirdly, we have a fast track once we decide something's going to go open that they know what steps they have to go through. And again, this is really important to keeping people motivated because they have to know that that option is available. So, I mean, this is really a company win as well as an employee win. You have to have a win-win, right? So why, you know, why would people want to participate? First of all, we're adding to our organization the ability to work on code in an autonomous way to master, to demonstrate mastery and also to create a more purposeful thing as you go. Increased peer recognition, I'm sorry, collaboration. There are times when two different people and long into two different groups want to work together, they have a cool idea. This has been a great way for that to happen. Greater recognition, you can show off your code to people and have them contribute. It's a way of validating your work. We also want to use this as a way of, again, increasing company recognition and rewarding them. And this is a framework that allows that to happen. As I mentioned, this allows them to participate in contributing out more easily. And also, it makes other people's jobs easier. A number of tools have been written by one group that someone uses just to make their job a lot faster. I was talking to someone the other day how someone published a number of build time scripts that they brought into their project. So I kind of addressed, you know, how we're doing this inside WinRiver. One of the things I often have to, you know, explain to people is how do they get to participate? How do they get to join in? So this is what we usually communicate to our employees. We use GitHub. All you have to do is register your GitHub with me to our private internal organization. Anybody in the company can go and grab code without asking, right? Anybody can create a repo. So once we don't question it, we say, all right, they request it, we create it. And finally, we have them visit Codeswap. We also let them know that if you develop something that's meaningful enough, we will select things periodically, announce them through email, and say, hey, we have this initiative. So what Codeswap is not? We don't use it to drive product development. We have well-defined processes in place, the agile scrum model, for example, okay? This is just to allow things to happen in addition to that. And again, I like to highlight that. We don't view it as the replacement to agile, although some people are exploring this approach to be their primary development model. And I'm not saying don't do that. I'm just saying we're not ready to do that. As I highlighted earlier, we're not trying to break down the silos. I believe that they're natural, they're gonna exist. You could just make things move across silos more easier. Right now, it's not really a corporate-wide initiative. We started out with a certain set of groups. Anybody could have joined, but we started communicating and marketing it to a certain subgroup, the IoT-related engineers initially. And now we're slowly growing it out. And I also like to highlight this approach is not for every developer. It's true even now. Not every developer wants to participate in the open-source world, although what we do find is a lot younger people joining the company. They're so much more used to this model, a way of doing things that the high percentage of those guys are gonna wanna participate. But even then, they're still people that's just not their thing. And that's fine. So what's next? I have to do more behind the scenes so people don't see it, but to help foster a particular community around initiative that seems to be taking on more momentum. I have to put together a video so anybody wants to participate, just say how they can get started really easily. I have to... Currently, we've been doing this for about 12 months, and now I have to take it up a notch in terms of visibility and continue. I kind of will admit that in the last three, four months, the evangelism piece has kind of mitigated a little, and I've seen the direct impact of that. And I have to continuously pick that up. What we're also starting to do is sponsor more internal hackathons. And I think that's been really well received. There's a lot of people who work on a lot of stuff to enjoy, but there are certain people that are working on things at the moment that just need to get through because the company needs them to do it, and they find these things as great outlets to working on something within the company with their peers that takes them away from some of the drudgery of their current day job thing. And again, as I mentioned, I have to continue to evangelize. Observations, if you're going to do something like this, obviously you want to start small, don't boil the ocean. I don't know how many people are familiar with the crossing the chasm approach to market technology adoption, but that idea is you want to go out and choose a small little group within your company and then focus and give all your energy there. And once they catch on, you move to another group and then you kind of grow it out that way. Not just spray it around to everybody. Centrally focus your energy. In our case, we went to the IoT group and that was really helpful. Again, I already mentioned, I think it's critical to have pathways to open sourcing. You want to make it extremely easy to participate, but again, there's a lot of behind-the-scenes efforts. You have to have someone dedicated to making and doing a lot of this grunt work, like putting up a webpage, making sure people's projects are getting up there, making sure the emails are going out and so forth. But as far as the developers are concerned, they don't see that. You don't want them to even have to worry about that. And there's a constant continuous pivoting or tweaking. Oh, I misspelled tweaking. Code reservation is real, meaning we have been able to archive a lot of code that would have been lost in the last couple of years by simply having an internal GitHub and a place that's open and a place of depositing stuff. Okay, so these are the points I already made. In summary, if you go and you make content transparent, if you go and foster the level of autonomy, mastery, and purposefulness people can pursue, and if you give them that simple enablement, it doesn't take a lot, we talked about that, right? You will find, you will get more things developed that you would normally not get. You're going to find definitely a cross-group sharing. You're going to increase the happiness of your employees and your company overall is going to just be a better place to work. So with that, I think, you know, our mission is really to really teach them the immensity of the code and then the same spirit achieve the same effect. At this point, I'll take questions. Yes? Yeah, yeah, yeah. Okay, okay, so the question is, we're wholly on subsidiary of Intel, but we're separate. We have our own firewalls. We have our own HR, but the question is, would this work as a sharing between Intel and WinRiver? The answer is the infrastructure absolutely works for that. It's not occurring at the moment because we haven't started that initiative. In fact, I've been asked to present this same talk at Intel, software development conference, internal conference in November. So that is my first attempt to bring Intel into this. Or, you know, and basically, but the infrastructure we have, the GitHub, you know, private GitHub, I can just, as long as I get a GitHub ID, I can add anybody to it. And it's a fantastic way to share code across subsidiaries, I think. And I'm very mindful of that, but we haven't taken that step yet, but I think it's going to happen. There's an opportunity to have that happen soon. Yes? So everybody is required to work on their, they're supposed to work on their normal projects and this is at their own time, their own initiative. Now, they could work it out with their manager to, you know, if they're working on something really neat, they can say, all right, can I spend some time on it? It's all for negotiation. But ultimately, this is kind of auxiliary. But what I have found is everybody does a great job of doing their day job and there's a tremendous amount of energy put into this stuff at night or, you know, right after work. We have an internal maker group and this is another place where this stuff has been really well received in terms of, the maker group is another grassroots thing that started within the company to build stuff and share, you know, among ourselves. And this is a great way they use it to share code and they do it after work hours. But again, it's up to you working out with your manager. Yes. I'll come back to you. Yeah, yeah. Yes. It's a good question. How much opposition did I get from management? Ultimately, you'd like to think that you have strong management, you know, buy-in. And I generally think what I had was a very neutral situation. They said, yeah, yeah, that sounds like an interesting idea. I don't know if there was a big strong support and pushed to support it. But they said, you know, go do it. In some ways, this is an open initiative, right? To start this internally, it was my attempt to do something that was grassroots, right? And I just went to the manager and said, we're going to do this. They said, okay, why don't you try it, you know, in a very focused way. And so I would say there's always possibility to opposition. And one kind of feedback I heard was, I'm a developer, I'm a manager, I have things to get done on a certain time schedule. I don't want my people messing with, you know, code swap initiatives, right? That's always, you know, that is sometimes a feeling managers have. They feel like this is a distraction. But the reality is, developers are going to want to work on things anyway, whether you're doing it inside the company or outside the company. And I explained to them that you're just going to end up with a happier employee. You're going to have greater retention. I know people work on projects that they're kind of dealing with, you know, drudgery at some moments. And this is such a great outlet for them. So I think management understands now after we had a few success stories. But in the beginning, they just didn't quite buy in. But they didn't stop it. Yes, I'll come back after you. The most what? Obstacle. My time. What was the biggest obstacle that I faced? You know, we talked about autonomy, mastery, and purpose. I did this for the same reasons. I got to choose to do it, right? I wanted to master this. I wanted to demonstrate my ability to bring open source development model to make it work. And I thought it was a purposeful thing, right? So I'm a victim of those intrinsic motivators myself. But the biggest obstacle was if you want to do this, you've got to find someone who wants to do it and who's excited to do it and almost for those reasons. It does take a lot of time. And I think it's hard initially for a lot of companies to come down and say, do this because it's just not something that's in their mindset, this way of working. But we have seen so many success stories. To me, it was like something really worthwhile, and I did it for that. So my biggest obstacle was just my ability to commit the time. Well, I think if you have one person who really believes in this mission to make this successful, that's like an open source project, right? You get that one person, right? It's a really interesting piece of code, and they put it out there. And they're really driven to make it work. And it succeeds because someone drives behind it. That's what I think you have to have to make this work. But again, my biggest focus is making, removing all the red tape or friction around the developer and interactions around this program. It's really important. You had a question. He had a question, and I'll come back to you. Okay, I can tell you we have 15%, a little more than 15% of developers who have registered their Git ID with me. So I know that those people are actually accessing the repository. This is one year later. Keep in mind that I was very focused on going after one particular set of developers. I said, you know, I want to go after the IoT guys. And I said, you know, this is really, you know, for you guys to participate. I did not prevent anybody else from participating. So it's just I haven't broadened the scope yet. So we have about 15% of the developers who have registered with the GitHub and who actually accessed the repos. I guess one more question, yeah. It's a hard one because a lot of people will grab code and you'll never know it. I think that's also being active, right? As far as contributing, we have about, I would say, seven initiatives inside right now that I consider to be success, right? One of the most successful things that I talked about yesterday at a talk was we're open sourcing this encryption detection script that, you know, different groups were all developing separately. We brought it together, and now we're about to open source that. Out of those seven projects, we're open sourcing three of them. And I think that's showing people, wow, that's cool. It works that I want to maybe that's starting to draw more people in, but it's hard for me to tell exactly what percentage of people are working on it. Is that it? Okay. I'll get him and then I'll come back to you, okay? And then, okay, yes. Okay, what do I mean by that? He's asking, I made a reference to that it's important for the employees to be happy, right? We want to use this to increase their happiness, right? The term we often use is employee retention. To be more exact, in fact, I went and presented to the HR department. And the reason why I did that, and they got really excited because when I looked at other companies, I looked at larger companies too, like Facebook and Google, they have a lot of developers they're grabbing from the open source community. And I explained to them, this is how they like to work. If you give this model, I told HR when you start interviewing people and you're trying to court them, let them know that we have this code swap initiative. And if they come here, they get to participate. So it's not just retaining, but it's also attracting. And I think it's the same thing, right? Because this is the way people really want to work. And people will forego, I'm not saying that it's going to forego money over this, but people, when you have equal money and this opportunity, I think this helps push them over. Yes, generally, yes, I think they're going to do it. In addition, they have to all do their day job, right? And every once in a while, we'll have code-a-thon, like a hack-a-thon, they get to do it on that time because we'll dedicate three days to a hack-a-thon. But for the most part, it's being done on their own time, but sometimes they could blur the two. Me outside, okay. Sensitive topic, your employment agreement. What I mean by that is, we all work for high-tech companies. And whenever you work for a high-tech company, I don't care who it is, you all have employment agreements, which says that certain things that you work on actually are property of the company, okay? And what that means is, if you go and try to give something out on GitHub, you can actually go and probably look at your employment agreement and decide whether you're working on something that's not relevant to your company and doesn't fall under that agreement. But it turns out that oftentimes, people are just working on a lot of stuff that is probably because of the nature of your agreement belongs to the company. Now, I know there's a lot of blurriness around that, and I really don't like to talk about these things too much because I always tell people, you know, you go figure it out. However, we do like to highlight, when we have three paths, I like to make it clear to them, there's just an opportunity for them to go work on their own time stuff, but that's very clear that it has to be something that, you know, not related to the company business, so there's no conflict of interest. But people have to look at their own situation and make their own judgment call, and they might. They might, yeah. Well, I guess the most important thing is here, the reality is if you believe you're working on something and it probably belongs to the company, why not have an infrastructure that allows you to do it there and then actually get it open sourced through a normal channel and get company recognition for doing it and helping your company. So I think this is actually an added value onto what already exists today. Without this kind of program, people are kind of stuck. They can't really go out. There was a question in the back, or are we done? Yes. Yeah. He's asking, does this work for distributed teams? Even more so. That is so much more a part of that, how the open source movement works. It's interesting, I see a movement among companies today. They're all trying to consolidate workers into a central location because of the Agile model. They believe that, I don't know, something like a number of eight people per group are best when they're working at the same site. And I don't want to go into do a big debate between Agile and the open development model. All of this, say, I think this promotes or supports or embraces a federated development model or distributed model. I think other models don't do as well. Any other questions? Okay, thank you very much for coming.