 How many people here are heading up kind of open source initiatives within their company? Small group here, okay. Okay. So my goal here is to talk about some of our experiences we've had with trying to get our employees to be more creative and also provide a more engaging place to work through our open source program office. I assume many people are familiar with the story of David Van Gliath. If you're not, it's the story of where a small little guy takes on a very big guy and wins through strategy and smartness. But the point I would like to make here though is that we see so many times as circumstance in the open source world where you have some small guy does something and ends up taking down a big guy. So I don't know if you're familiar with Samuel Langley, but he was very famous back in the late 1800s, early 1900s. He was the guy who was supposed to come up with a flying machine. Okay. He was highly funded. He's a well-established professor, secretary of the Smithsonian Institute, and ultimately he had all the items to be successful for building a flying machine plane. On the right side, you have the Wright brothers, and what they had was the opposite situation. They had very little. They basically were bicycle shop owners. They had no funding, no college degrees, no other team members. Langley had a whole large research team behind him. In October of 1903, Langley went off to launch his first attempt prototype of a plane. They slingshot it off a cliff and it crashed in spectacular fashion. Okay. Two months later, they tried again and they had similar outcome. The Wright brothers seven days later, through their own efforts and methodical process, we're able to launch and successfully have flights, and we know that this history since. The key thing here though is when you look at the motivators of these two sides. Now, by the way, it's fair to mention, there's a lot of people who are chasing the goal of building the flying machine, but these are two core participants that really stick out in history. In fact, Langley has a number of buildings named after him in Washington DC, so he's not like small stuff. But the biographers have said that he was highly motivated by a sense of wanting to obtain fame, fame that similar to other guys like Bell and Edison. Where if you look at the motivation on the right part of the side, they were largely driven by this notion of pursuing a passion where we refer to as scratch and itch, something we're familiar with in the open source world. Our goal here is to find out how we can tap into that kind of motivation and how a small team can take on a very large team. Now, if you're not familiar with the scratch and itch principle, it came from Eric Raymond through a classical article he wrote back in 1997, the Cathedral of the Bazaar, where he refers to a number of different concepts that describe why open source is successful and what makes an open source initiative. But he has this one definition that people cite from time to time, and that's like every good piece of software starts with somebody wanting to scratch a personal itch. We want to tap into that motivation inside our company. Now, there's other classic stories of this, of David and Goliath. Linus, again, he wasn't his intention to take on the UNIX players of the world, but because of his motivation to pursue something out of passion, it's amazing how far he went. In fact, this is the first posting, there was no Twitter back then. This is a news group. Basically, he posted his code and he said, I'm doing this as a hobby. Come and check it out. Here we are 30 years later, and it's an amazing accomplishment. So, when we had to ask that question, why in the open source world is there so much success, where there's no financial compensation, no large teams, but there's that basic drive to scratch an itch? So, we went off and studied what makes these successful, and we asked ourselves, what can we do to bring that program inside our company? So, the Y really had two real goals, value creation, and when I say value, it can mean many things to many organizations. For us, these are some of the areas we wanted to see our developers contribute to through pursuing certain passions to solve problems. It could be an open source project, it could be a new feature to a project. It could be a new tool used across projects or teams. It could even be a community give back. Okay, so our goal was to say, all right, if we can create a program internally that can motivate our employees to pursue their own interests, what can we do to achieve these? But also, there was another point here. When you look at the RIPER others, and you look at Linus, you probably have to ask, did they do it for the fun of it? Likely the answer is yes. There was a lot of joy in it. So I also wanna highlight that we're trying to inject joy into our company through that process as well. So there's two goals, create more ingenuity for our engineers, but also create a more engaging workplace. And I use this image to kind of reflect when, when we're all young, we all did certain things that we remember, they brought that sense of joy. And unfortunately as we get older and older, we get squeezed into the box of the world, puts us in, and we don't have as much joy. But I think this outlet that we offer to our developers gives them that joy back at some level. And I use this image to reflect that throughout. This is a theme I use. So what did we do? Essentially, we wanted to define a method. These are just examples of existing methods, far more prominent out there in the world, but I wanted to give you a sense of what the target was. Create a method, okay? Not just a piece of software, but a method. And when I say a method, I mean this is our definition of the method we're looking for. To use open source principles, to empower, to foster, and to harvest, not only in unity, but the joy, to all those within our organization, okay? Okay, how did we do it? So we need to study obviously the open source world and different projects, but also human nature. And so we looked at four core areas that we wanted to do. Looked at human intrinsic motivators, understand the open source principles that drive open source projects, come up with a workflow and a playbook, and then build the enabling technology, okay? So the next three things I'm gonna point out, the three key human intrinsic motivators that you find in the open source world were documented by Daniel Pink in his bestseller book called Drive. We'll pay. And each of you can probably identify at some level with these motivators. So when you can give someone more autonomy, they're gonna be more productive. You can give them more money, but research has shown giving them more autonomy generally leads to more productivity, okay? And when we say autonomy, we're generally thinking about delegating as much as you can, giving them choices, getting out of the way, having as few mandates as possible. When you dictate to a developer, here's the requirements for a product that you have to deliver to. Yes, they'll do their job, they're professionals, but that's not nearly as exciting and they're not nearly as productive as they are when they actually try to, when you give them more freedom. So I like to highlight, in the case of Lennox, people go to Lennox because they have that autonomy. They choose to work on Lennox. They come at their own time, whatever area of Lennox they wanna work on at their own choice. Wikipedia is no different. It's an open content. People come there and work on whatever topic they wanna work on, however long they wanna work on. And we've seen that that actually has led to great success and again, no financial compensation is involved here. The second one is mastery. Intellectual workers in general, and people in general, like to master things. Think about your own lives. Think about maybe outside of work, you have a certain hobby, maybe it's a sport, maybe it's an instrument, a musical instrument. We somehow like to master things at some level and then demonstrate that mastery to our peers. And so, and by the way, in the coding world, a lot of developers sometimes wanna get really proficient at a certain kind of technology. It's no different. So, and again, if you think about mastery, a lot of people go to participate on Lennox to show mastery of a certain kind of core technology or Wikipedia, why do they write those topics? Why do they want to be part of Wikipedia? It's a demonstrate mastery and again, it's about peer recognition and even Linus Tarval said that he actually threw out this code because he was excited and he wanted to show it off to a small group of people. Okay, so if we can capture mastery, again, it's gonna be much more powerful than a financial compensation. And finally, the third one is a little, it's obvious, but you have to be mindful of it because you have to incorporate it into your program. It has, people are very driven by a sense of purpose, right? Clearly, if it's something to help the environment, feed the poor, right? Those are very meaningful things and people will do great things with great efforts without much financial compensation. By the way, people contribute to Lennox, right? Because it's very meaningful and purposeful, right? And they'll contribute to Wikipedia for the same reason. So not only those examples, but they are meaningful, purposeful missions like most open source projects are, okay? So again, people will do great things for a meaningful cause, whether it's for a friend, a team, or the world, okay? So we wanted to make sure they were captured in this method. The next thing we wanted to do is obviously look at open source principles that drive open source projects, right? And being in the open source world that I would assume everybody here is, I assume you understand these basic things, but I wanted to highlight really quickly what we wanted to make sure we included, right? When you think about open source projects, why are they successful? Clearly, we discussed scratch and itch. But there's also that sense of transparency. The more transparent and open a project is, the more successful it is, the more closed it is, the more it becomes infighting, fractioned, and so forth, right? You cannot overstate the importance of communication and collaboration within an open source project, especially because everybody's dispersed all over the place. Clearly, we wanted to make sure that was there. Meritocracy, it's kind of an accountability thing. Meritocracy is very important to developing respect and getting influence within a project and being able to honor that and giving credit for that. And then finally, community, we do a lot of discussions here about how to grow a community. So I just wanted to highlight that these are additional five requirements into building this method. So now we have talked about human motivators that we wanted to make sure we got, we captured, and also the open source principles. Now, let's talk about the workflow. So everybody wants to know that if they submit an idea within their company, they want to be able to track it. Oftentimes things will fall through the cracks. People will do hackathons and also they'll submit these great projects and somehow they get archives somewhere and no one knows where they are anymore, right? We wanted to create a very open system where you can track your idea and understand where it is along this progress towards adding value to your company, okay? So you have an idea, right? Anybody can submit an idea. Then we allow that to mature to a state of proof of concept, demonstrate feasibility. And then finally, we want to look for impact. Remember that we'll go over impact again, but it's whether it's a feature and open source project and inner source tool. Ultimately, you want to track ideas through these three stages and so everybody can follow along and see where they're at. And then finally, of course, you're gonna want recognition. And we'll talk a little bit about that later. Okay, so just to give you a sense, pull up our portal. By the way, we've open sourced this. And it still needs to be evolved to be a very general purpose platform, but we decided to throw it out there to start that process. We had about 155 projects right before this talk. We cleaned it out to 140. But here, if I go and open it up, you can see all the projects and you can see the stages they're in, right? Everybody can see this. It's open to everybody. And so if I wanted to, I could even sort on the different stages. You can see certain things have gotten to impact. Okay, that's the most important part I want you to understand. I also can give you a sense of how you might look for another project. I might look for a search of certain project. I can open it up and up comes a webpage for that project. Every project gets their own webpage. Oh, thank you. Excuse me. Okay, unfortunately a good part of the presentation is showing off the portal. Okay, we'll do our best here. All right. Move it along. All right, so I mentioned that there was this three stages, right? And the third stage is on the other side of the line. I just wanted to create a certain separation but really remove that. To let people understand that things can go from idea to proof of concept, but these are the different pathways that you can actually achieve success or value, right? And the other thing to also highlight is that you're gonna have a checklist for each of these areas. Not everything is gonna go through very easily, right? This is where you get to be very consistent and firm about requirements, about what makes it into each of these categories, okay? And so each of them might have their own criteria. What I'm trying to highlight here is that you want people to generate ideas but not every idea is gonna end up where they think it will end up, okay? And of course, something can go from one group to another group. I can have things go from intersource to open and I can have it go to product feature, all right? The key here though is people have to understand what is the pathway they have for their idea? What's that purpose? What impact and meaningfulness can they have? The other point is there's a certain kind of ratio of what you would expect from a project in terms of you have certain ideas come up but the percentage of ideas is gonna be much smaller of ideas that go through the system and that actually ends up making an impact. And that's the only point I wanna make here is that even though you'll have a lot of ideas, you want them to come. Because a lot of times people say, oh, we don't wanna let this group create a GitHub repo because we wanna control how much it goes out and you don't want this to turn into a graveyard. I have a different belief. I think you need to let people create stuff but have a process which allows them to filter through and then allow them to go. Because something could sit for five years, we've had something sit for five years and then actually get recognized again and pop up, in fact, the Zephyr project. I don't know if you're familiar with the Zephyr but that started out as an internal project at Wind River. It sat on the bench, on the shelf and eventually you got turned back out and made open source. So things can sit for a while. Excuse me, sir. Can you get, this is not the actual display of my, it's not displaying the actual screen of the web browser when I pop it up. So when I come here, it's not showing up there. So what we wanna do is go into your settings. Let's minimize this. Don't close that, just minimize, let's go to the desktop. Okay. And go, so minimize that. Right click. Yep. Display settings. You wanna duplicate. So that's extended right now. So if you duplicate, go up one. That should show both. Okay. Thank you. Mm-hmm. Okay. Okay, it would be just easier to show you, thank you, than to talk you through it. Okay. So I'm gonna jump into what I would consider to be the eight pillars of our method, right? But this is an evolving method that we're hoping to bring other people in and help us develop it. Okay, so the first one is, there's zero mandate to participate. The one thing we have to be mindful of the fact is not everybody wants to participate in open source. It's just sometimes in their nature too or not to. Okay? Similarly, you don't wanna prohibit people from participating, you don't wanna create an exclusive club. A lot of times people look at R&D groups and they say, oh, they do the R&D stuff, right? That's their thing, right? No, you just wanna allow everybody to come forward to scratch an itch. The process should be frictionless, right? And what we mean by that is, sorry, it's not responding to my screen. So what I mentioned before is it should be frictionless, okay? So here's the simple, it's four lines. Fill in an idea, you put in this brief description, you check a few boxes, and then you add the people who are participating in it. Okay? And then you submit. And it ends up automatically on the list, okay? Then we have someone who will come in and they'll look to help them develop a webpage and start to promote it. It's not showing this now. You're not seeing my PowerPoint now. It's not showing the PowerPoint. Okay, so we, okay. Do a bit display, right? Yeah, did switch. Keep, okay. Good, all right. Sorry about that, all right. So I wanted to go back and forth between these two screens. So let's move on here. So I mentioned it's frictionless. The other thing is we already touched on it was tracking. Tracking is really important. People want to see where their idea is at at all times. Complete transparency. We talked about that a little earlier. It's important for trust and people understanding that anybody in the company can go and look and see what's going on. They can either see their project and everybody else's up, everybody else's projects. So we mentioned that by having that portal, that's you achieve that. High visibility. We talked about creating kind of a marketing opportunity for the project, right? When I talked about the smart meter, right? I'm sorry, the smart speaker. You basically have an opportunity to not only have text, but you can have the slideshows, some videos, or even the source code, right? And then what you want to do is have someone who's responsible for marketing it. Developers don't like to do that. They're going to want to come and develop their code, put it out there, but you need to be out there championing them, lobbying it. So I'll go to different product marketing managers and say, hey, we have this great idea. And then they'll look at it and they'll eventually put it into the roadmap. Or someone will have a tool that obviously other teams can use, and we'll talk about examples of this. And I'll say, let's get a common project together and share it and develop it. So you have to have obviously someone behind the scenes doing a lot of managing of the project. And finally, there's recognition, okay? So these are what I would consider the core things that you have to have in place in order to achieve what we're trying to achieve. And then finally, with enabling technology, the best thing to just show you examples, the things that have succeeded through the program, okay? So again, I want to remind you that when we think of value creation, it can mean a variety of different things. When I go back to the portal, we'll see examples of that. So let's go here. And the first thing I'll show you is something that ended up to be a feature of a product. So this risk, so we have a proprietary operating system that supports ARM and X80S6. And we had someone who was very curious to see if we could support risk five architecture. So they took it on their own initiative. They wanted to scratch an itch, right? And they went off and they just did it. They came back, they did a proof of concept. And then eventually the product team said, this is really neat. Let's go ahead and put the development resources on it at that point in time, not that person. But the development team, because it was on the roadmap, became a product, a feature of the product. Okay. So another example would be something that we open sourced. So TensorFlow is a very popular library for AI. And we had this one team develop the solution on top of Lennox. They did it internally for a hackathon. We thought it was really cool. We tracked it through the system, went through proof of concept and eventually they were able to go to the Yachto project and actually have, you can click on the source and you actually go to the Yachto project. So this is something that it became open source. Okay, and I'll show you another example where something became an internal tool or an inner source initiative. So we had the need for different teams had to fill out export forms. I don't know if you're familiar with that process. You have to do export compliance. A lot of times you grab open source packages that has cryptography inside it. You have to really fill out those forms based on what cryptography is in the open source packages. Well, if you're grabbing hundreds or thousands of open source packages, no one has the knowledge or the expertise to determine whether you have cryptography inside those. So we had a developer develop a tool for their team to scan and look for cryptography algorithms and uses of cryptography. Obviously other teams can benefit from that. They actually developed the tool and we eventually had multiple teams used it. We said, all right, we'll declare that as impact, adding value and basically that tool is then used and now it's available to all our teams through internally, okay? So all the teams can now use and use the same program. I think you get the gist of what I'm trying to go over here. The main point is we were able to show several examples of value but your organization might have a different perspective of what value is but I think the basic principles are the same, okay? So I would say in summary, because of this basic workflow and it's still in a work in progress, right? We're still evolving it but we think that we've achieved some really good success. We probably had about over 30 projects that have gone through value. We have over 140 that are currently tracked and they're coming in every week. And by the way, the way they come in and sometimes it's not just a hackathon, we have innovation sprints or someone just wants to submit an idea, okay? Finally, what we do is every time we have someone achieve impact, what we do is we have a committee kit together. We evaluate the actual different initiatives and then they select and then we actually announce that you are all hands meeting. They get an innovator, certificate and other things. You can choose to obviously reward people any way you think is necessary but interesting enough they do it all for the recognition, the basic recognition, right? So some considerations to think about. I know a lot of people talk about they want to change culture. I think of it more as growing a culture and the difference is changing cultures kind of suggests you want to change the way people think about a problem but you really want to create a program that has high incentives that attracts people in based on the human nature that they have, right? And it's up to you to make it very enticing and by studying those motivators, that's what we did and people, they're just coming because they like to. Now keep in mind that in the second point it's not for everyone. You know what? Think about how many people, does every developer contribute to open source? No, how many feel comfortable doing that? I don't have an exact number but I have a concept about, I'll throw it out as more of a concept. I think about one third roughly of developers generally want to contribute to open source. Maybe it's larger than that, maybe it's 40%, maybe it's 50% but not everybody does and so you don't want to force people to do something that's not in their nature. As I mentioned, a great source is hackathons and innovation sprints. You will generate many projects. I know a lot of people are reluctant to let that happen but I think as long as you have a system that's worth trying to propose here to manage that complexity that is actually very powerful to allow people just to go and not have any, you want to reduce the amount of restrictions or mandates. Clearly the obvious thing is the higher you can go up in corporate sponsorship the more successful you're gonna be. People just pay attention and it has more visibility for that simple reason. And simply it's easy actually to gather data here from all the successes you have for Hinting Impact and go back to your organization and say, hey, we have successes. This is what we do. We have a program in place. It's very clear. It's well documented. We have them. We track them through these different stages and we have all these different categories and where we're having impact. So yes. Well, if you look at the different, but- Is your data safe as far as the question, do you use data? Yeah, yeah, yeah. Yeah, yeah. Is your data safe? Yeah, yeah. She's asking what kind of data are we gathering and how do we use that data to measure success? Is that it? Yeah, okay. So in the most basic sense, but every time we have an impact, we clearly have winners. We clearly have people who are succeeding. We clearly can measure how many people are at proof of concept. And so I talk with inside the company, I say, what are the categories we wanna hit? Now by the way, we have some projects doing community give-backs. And we have a group in HR that wants to measure community give-backs. So by having those different buckets, whether it's open source projects created or new features to a product or internal tools developed, it's clearly measurable by cause you're clearly tracking it. It's almost like it screams out at you. So those basic things you can show, and you also have the awards that show as well. Yeah, so at that level, I think it's very visible, very easy. So in summary, really we do, we really wanted to foster employee ingenuity for sure. We wanted to get a bigger bang for the buck, right? But also we really wanted to make it a more fun place to work and by engaging people through this scratch in its principle. You know, we're powering our employees by tapping into their passion, their passion gene, their scratch gene. We built upon studying how success has happened in the open source world. And by the way, it's not just the open source world that these motivators and factors play into. You look in the academic world as well. We wanted to create a reproducible method. Again, it's a method, but it has supporting workflow, playbook, and technology. The results exceed their expectation. I still consider it like a pilot because we're a company of roughly 3,000 people and we're having this kind of success. I do think larger organizations are gonna have different kinds of experiences. But I think that sometimes, I've worked in larger organizations and I think sometimes people feel lost inside a larger organization and this will allow them to empower them to be able to put up something without having to lobby 100 people to get something going, right? Again, we don't wanna inhibit anybody from doing that. But clearly in a small organization, it's a lot easier to get visibility on it. And finally, my goal here is to show that we have some good experience. In some ways, this project, this method, whatever you wanna call it, was a, we call it the balance program, was a balance initiative, just like anything else was, right? So, and we're trying, now we've gone through proof of concept and we're now at an impact. So I'm hoping to take it next step is to go out to the community and start to develop this and develop the technologies to see if we can get other companies to use it and build on it and benefit from it and also communicate that to our customers to help them be more innovative too. It's partial Y, okay? And finally, I'm looking for the ability to take this to the next step. Like I said, the code is open. It's on the Apache license. It's been designed to be of general purpose for any organization but it still has some work to be done there. We're always looking for different people to participate at different levels, clearly if you have your own experiences you wanna help develop the workflow, the playbook, you wanna contribute the source code. The source code is ViewJS is the front end and although we're using Google Fires for a database we're looking to go to a go backend and Postgres. Clearly we need people to help develop and write up articles and blogs about this initial approach and to evolve it over time and also people to help with outreach. If you're interested please contact me after. With that, I'll take questions. Yes? Can you say a little more about the staffing and capacity required to manage this and facilitate this and how you see that scaling relative to projects and organizations? Great question. We want to understand what kind of staffing. Yeah, yeah. He's looking to understand what kind of staffing we might need to support this depending on obviously the size of the organization. Right? And the volume of projects, yes. It's a great question. There's no doubt that you can be overwhelmed with people submitting ideas and you definitely don't want people to feel like they're going unnoticed, right? And so that's the danger of not staffing properly. My experience is that one person, by the way, I had this project managed by interns. I hire interns to do it. Like I'm looking over the whole process, right? I have interns work on the web portal. I've had interns help with the playbook and also reach out and evangelize and talk to the different groups and touch them, okay? I'm not saying that's the best approach, but I would say you definitely want, say 200 projects, I'm guessing, you want to have a full-time person monitoring that, right? That's my initial gut. One of the goals of this platform is to make it so that when you scale up, you can actually have a lot better way of organizing the different projects. But I would say there's, as you get past, say, 400 or 500, that's a full-time person, probably. And then you have to ask yourself, what's the impacts we're getting and is that justifying that cost? But you can definitely do it with, you don't have to pay a principal technologist to do this, but you definitely can, you want to bring in someone, especially a person who likes to be kind of that community organizer person, because it's really about the human side of touching those projects, keeping them up to date, tracking them, checking in with them, and so forth. So I'd say at 500, you probably, it's kind of a lot for one person. I don't think I have a lot of experience to talk about how to scale this yet, beyond that, so. Yes? It's helping align the types of companies, goals, and resources. Great questions. So the first one is what kind of success are we having for the number of submissions we're getting, right? We have a little over about three dozen success stories, right? And so they're either inner-source tooling or it's an open-source project or it's a feature to the company product line, okay? So that's kind of success we're having, but I still consider it like a piloted project. The other question was about how do I manage people's disappointments when they want to submit an idea and it's not going as far as they want it to go. I would say to that is one of the number one things I see is my role in serving this project or whoever's evangelizing it for us is to do whatever they can to find impact for them within the company. But everybody understands that they're gonna submit something and it may not get there. But we're gonna work hard because we have many avenues for that impact and we wanna find impact. So we're gonna work hard towards that. However, I think people are okay every once in a while. They understand that they had the ability, it wasn't like it fell through the cracks, it was there, it's still there. And I always tell people three, four, five years from now it can still be something that we resurrect, right? But sometimes they just lose interest too and it's okay. So I haven't seen so many disappointments. I think they've been overly appreciative of us being there, being able to put it into this machinery and have it create visibility and getting exposure that they normally could not get within any organization. So what was your third question? Are you, for example, are you announcing certain strategic goals and asking for proposals that solve certain problems? So one feature I haven't talked about, we have something where anybody can come in and put a challenge out. And then developers can go there and see what challenges are being asked. So I was looking for an autonomous drone demo in marketing, right? And so that's one way we've dealt with that. If I go back to the portal, I'll just show you real quick, we won't go through it. But challenges, anybody can post, this is more the business side, can post a challenge. These are just looking for a place for someone to do something on a project that no one's been picked up yet, right? And so they can actually list out different things there. But I shouldn't, I haven't really vetted that list so I don't want to present it at length. But the point is that we want to create part of that portal the ability for the other side of the business, the ones who are looking for certain things to post what they're looking for, like a wanted ad. But keep in mind that one of the things I really want to protect is that scratch and itch thing. This is the first and foremost, you come with an idea. And by the way, R&D teams are gonna exist within organizations, they're formalized, they're well run, whatever. But that's different, that's something that most employees cannot participate in. And this is more about the scratch and itch. Largely, that's the primary focus. However, we do want to create this idea that you have a list of items that the business is looking for. And if you have a hackathon going on or an innovation sprint going on, go there and pick and they do. They do that sometimes. Any other questions? Okay, if you're interested in following along, participating, I'm definitely opening this up to be more open kind of initiative. We posted the code out there. It's still very young in its infancy. And the goal is to get more companies coming in and putting more requirements on so we can involve this to be more general purpose. Obviously our company's developed it internally. I really want to move away from that internal structure and have it be more robust as a general purpose. And the only way we're gonna get there is by engaging other companies. So don't hesitate to reach out to me. I do appreciate your taking time out to attend the talk. Thank you.