 Anyway, welcome everyone. This talk is going to be about Inner Source 101 and the Apache Way. That little icon in the middle between the two feathers is actually the official logo of the Inner Source Commons, which is a group of companies which are trying to consolidate information about how we are embracing Inner Source. It's actually sponsored by PayPal. Oh, thank you. It's actually being sponsored by PayPal right now, who have been very influential in the Inner Source realm. We're looking at actually spinning that out as well. So if that's something that you're interested in, see me afterwards and I can give you the magic karma to join Inner Source Commons. If you're familiar with the to-do group, it's sort of like the to-do group for Inner Source. A little bit about me. I am what is affectionately known as a gray beard. I've been with the ASF Apache Software Foundation basically since before there actually was an ASF back when it was called the Apache Group. I've served on a number of boards. I've worn a number of different hats and things like that. Two big things I want you to really remember is that I am really at heart a developer. So this is really a developer's look on Inner Source and the Apache way. So really take that in mind. Also, this is my own personal point of view. One of the great things about the Apache way is that there are some core tenant behind it, core beliefs, but we all express those beliefs differently. And so I want everyone to remember that this is me with my hat on as just myself, a grumpy, curmudgeonly gray beard. What is Inner Source? Okay, we're familiar with the term open source, but what is Inner Source? Well, basically the idea about Inner Source is that really when you think about it, open source should not be successful. Here it is, you have a project. Most probably without a known defined concrete roadmap, for example. With people and contributors distributed vastly all over the geography, lots of different cultures, lots of different abilities, and things they can bring to the table as far as these communities are concerned. There's no real face-to-face communication. Really when you're thinking about it, these kind of efforts should not succeed, because there really isn't that much of an organization above it controlling it, which is really when you think of software development, how things have usually been done. You were given a set of things to do and given the marching papers to do it. But what we've really seen, and it's been proven time and time again, is that really the way the open source community works, the way the open source community develops software has some incredible benefits, both tangible and intangible. But it's using Inner Source is all about taking those lessons learned, taking sort of like that secret sauce of how successful open source projects and how successful open source communities work together to develop this software and bringing that stuff in-house as much as possible. So it's almost, in some ways, treating your internal projects as if they were open source projects. And we'll talk a little bit about that, all the things inside there, and things like that. I've seen a bunch of these talks from other different people, and my talk is a little bit different because I tend to focus mostly on the principles, the why of Inner Source, rather than the techniques. Oh, this is a checklist, you should be doing this, you should be doing that, you should be doing that. I think that misses the point, because the idea behind Inner Sourcing is taking these lessons learned and translating them so they are really, really effective in your environment and for your industry. So why do people move to Inner Source? What is the draw of using Inner Source in today's environment? You know, especially if you are a tech company, but even more so, what if you're not a tech company? I work for Capital One. I'm a senior director at Capital One. Capital One is a bank that is making a transition to a tech company, but really, it really isn't a tech company in the same way that IBM and Hortonworks and Netflix are really, you know, Amazon are tech companies. What's the drive? Well, first of all, is that you want to gain those efficiencies of using the Inner Source models out there. You don't want your engineers having to constantly recreate the wheel, redo things, which really happens in a lot of environments where there are these siloed dangers inside of corporate IT. You know, this team is working on this project, this other team is working on another project, and there really isn't the opportunity of cross-pollination between those two. And it's that cross-pollination which helps you realize what some of these efficiencies are. Another thing that has been proven in the open-source world is that you really develop software better, and the software itself is better when you're enabling collaboration between teams. Not only inside the team, although that's very, very important as well, but if you can go and leverage talents from outside that team and allow true collaboration, you're able to basically create a mindset and a view which is beyond that of a particular team, that's where innovation comes from. That is the power that drives innovation. So the more that you can provide opportunities for people who are not only on the project but outside of the project to collaborate, you're able to drive that engine of innovation inside there. And of course, you know, you're also using it to, you know, the standard reduction of, you know, reuse, code reuse, bringing products, you know, all these normal, typical Mom, America, Apple Pie kind of things. The normal things that you think of when you think of open-source, why do people use open-source? Why is open-source particular? They directly map into also what you're doing and the leverages and the gains you're having where you're using these open-source methodologies inside of your company itself. Now, since I also said this is also about the Apache way, well, let's talk about that. Let's talk about what the Apache way is. And basically, as I kind of alluded to earlier, it's sort of like the basic tenets of what powers the way that the ASF operates and manages and creates communities. You know, that's basically what the Apache way is. Let me just look at something. Yeah, okay, so I'll focus on that a little bit later. So the Apache way is basically like the secret solve of the ASF. Now, other foundations, other open-source projects have certain governance models. The Apache way are the basic ones that we have to. So one of the aspects of the incubator, the Apache incubator project, if you're a new project wanting to come into the ASF, one of the things the incubator tries to do is to instill these values, instill these common thoughts, these common methodologies, this sort of like tribal knowledge that projects need to know for them to be able to succeed at the ASF. And so there are some low-level basic governance principles behind managing an open-source project. Now, why do we focus on Apache? Why is, you know, in a lot of ways, and I think other people even admitted, inner-source itself is really based on using Apache as sort of like the first model. Not the only model as far as what a successful open-source project is, but basically one of the tops. And the reason is because we have this, this heritage of being able to create really, really fantastic software projects. We've had a lot of successes. We've also had some failures, and we've learned from those failures, and we've been kind of open and upfront about those failures as well. And in almost in all cases, places where the Apache way has failed have been places where we haven't really had the Apache way as implemented as possible. For example, too much control and influence over a project by a corporate entity, for example. That's something the Apache way is supposed to avoid. Sometimes that stuff sneaks in and we've seen in those cases it can be damaging. Sometimes you're able to recover from that damage, but in most of the cases when we've had failures of projects due to do it, it's due to those kind of issues, those kind of problems that we've seen. The other thing too is that if you're trying to move into inner-source as a methodology for your company, chances are very, very good that they're familiar with open source, they're familiar with Apache. So you also have some immediate street credit that, hey, we're just trying to emulate the ASF inside of our company. That can help you also, especially if people are really, really hesitant about this newfangled thing called inner-sourcing. So again, leveraging the power of Apache helps bring that inside there. So what are the origins of the Apache way? Let me just tell you a small little story. This is basically the origin of the ASF. Is that back in 1995 or so, there were a couple web servers out there that people had businesses reliant upon. But the most probably the most popular by far was the NCSA web server. These were the people who not only created the web server, but also the web browser itself. Now we were all very, very happy because there was this one particular person, Rob McCool, who was developing and doing a fantastic job developing the web server. But he got an offer that when Netscape finally bloomed, he moved over. So here it is. There was a bunch of us, in fact, a bunch of people all over the place, who were now dependent on a piece of software that no one was maintaining. There was no one behind it. We had basically hooked our cart onto the NCSA web server and it was driverless. It's a terrible place to be, especially if you're a young business, if you're a business focusing on something, especially if you're someone who wrote the protocol behind HTTPD and you wouldn't see it really grow and flourish. That's a huge void. That's a huge vacuum that is scary. So a number of people got together and decided we're going to bootstrap this. We will be the horse that helps drive this. So mailing lists were put together. We started collecting patches and other information and basically created what we called the Apache group. One of the things behind that was that we realized, first of all, how difficult it is to reboot and reenergize a dead project. The other thing is that we were dependent upon something that really had no guarantee of longevity. We saw that. We saw one person went away and all of a sudden, poof, we were in bad, bad shape. So we swore, even though we didn't like all get around the campfire and chant and say this is what we swear, but we swore we would never let anyone who used our software be in that position again. We're going to do everything we can to ensure that with the ebb and flow of corporate interests, of developer interests, developer time, free cycles and stuff like that, that no community that is based on where the leverage is or consumes or depends on Apache software and Apache project is ever left in the same situation that we were. It's like the bird hand learns best. That's awful. We don't want that to happen to anyone else. So you'll see that most of the basic things that comprise the Apache way is from that era, is from that mindset. From the mindset of creating a project and a community that is long-term, healthy, and sustainable. And everything else is just how do you do that? So some of the basic memes, and we'll talk about all of these in particular point, is the idea of meritocracy, peer-based, responsible oversight, things like that. But even looking at this, you can say, okay, kind of like see how that fits in with the origin of the ASF. At the very beginning, let's talk about meritocracy. I understand that in some realms, the term meritocracy is seen as a bad word. And for me, it's not the term itself which is bad. It's what your definition of merit is. If your definition of merit is dependent upon whatever genitalia happens to be between your legs, that's an F-dub version of merit. Don't play meritocracy for a really, really bad definition of merit. Really, when you think of it, think of it as a duocracy. The more you do, the more karma you know, that's horrible. But how much merit do you gain? How much karma do you obtain? Well, the more you do, the more we're going to let you do. This is because it's based on what you do as a person. Whatever those contributions are, it's not just software. It can be code, evangelism, graphics, any kind of thing. That's merit. That helps grow the community. That helps improve the project. By proving yourself as yourself, we're giving you more things to be able to do. And so, inside the ASF, there is this clear progression that everyone has the ability to achieve going from users to committers to project members to contributors, committers, and even ASF members in there. And the only thing that holds anyone back is the idea of how much you do. Now, what's really, really important about this is the idea that merit never expires. And again, this goes back to the old days where we were all doing this as volunteers. And so, sometimes life happens. You have a baby, something like that, a job change, and you don't have as many free cycles as you had before. But when you come back, you don't have to start at the very, very bottom again. That's not very, very individual, contributor-friendly. No, you could be able to start off exactly where you were before. Same way with other things as well. You want to maintain a definition merit that makes it easy for people to have there. Peer base is also very, very important. And another way of looking at this is a very, very flat organizational structure. Why this is important is because, again, if someone's been there for 10 years and you've already been there for two months, there's this idea that I could never have as much influence or impact or be able to drive the community or the project as much as that person will because I'll, even if we stay on keel, I'll never pass them as far as years of merit or something like that. So merit is great, but it flattens off. The idea behind that, again, is to create an environment where you're always welcoming new people. Fresh ideas, new talents, and things like that. So the idea that it's peer-based, that what you do is based on you as the individual, and not basically who's paying your salary, is very, very, very important. And again, it's one of the major things between our mantra of community over code. Some people call it community before code, community as code or something like that. But the idea behind it is that if you focus time in resources and talent on creating a healthy community, a healthy project, a healthy code base, simply comes along for the ride. It's a natural outflow. It's much easier to do that. And so the idea of poisonous people, people who might be fantastic developers, for example, fantastic coders, but they disenfranchise other people, they kind of like you really tick people off and push people away, or they say, you know, I really don't want to go and work, you know, contribute code or whatever to this project because there are some really, really nasty people there. We really don't like that. We push poisonous people out. Okay, we're really, really stringent about that. And it had been from basically almost the very, very beginning because that is one way of poisoning the community and poisoning the longevity of a project. And the health of a project and the health of the community are incredibly, incredibly entwined. Some of the things you'll see when we talk about peer-based, you know, collaboration is this idea of voting. The important thing I want you to take away from here is it's not by, you know, it's, we use voting basically to gauge consensus. Does everyone feel the same way or not? Okay, so you'll see plus ones, minus ones and things like that. We don't say, ah, well, you don't have enough votes, forget it. We're going to force this change through. Unless it's universal, people will stop and say, hold on for a second. Why isn't there consensus based on that? Again, you want everyone in the community, they feel just as empowered to express their own point of view. And this provides an opportunity and a mechanism for their express their dissatisfaction and the ability of the community to hold back and say, okay, well, we're not going to just force through with a decision. Somebody's got an objection. Let's figure out what that objection is and work on achieving a collaboration. Collaborative development is also very, very important. Obviously, everything the ASF does is open, transparent on mailing list and we'll see how this really ties into to intersourcing as well. Talk a little bit about the responsible oversight in which everyone feels personal or responsible for the software. Okay, I may have contributed a patch, but if it goes wrong, sure, I feel responsible for it. I feel really bad about it, but the entire community, the entire project feels just as empowered to change it, approve it, veto it, and things like that. Okay, everyone is responsible. Now, think about this in the normal traditional IT communities inside your development where a developer, all I do is develop the code. When I'm done, I throw it over to QA. Anything screws up, that's their problem. I'm a developer. I develop code. I don't test code. When it goes to production, that's not, you know, as long as you can maintain that sense of ownership of code inside of a project or inside your IT community, inside your development team, inside companies, that's very, very powerful. A lot of this is really, really almost meta. It's much more about community than software. And it really, really is, because for me, this quote from the author of The Little Prince most probably goes to the best way of emphasizing what Apache is about and what Inner Source is about. And I'll react, actually, if you want to build a ship, don't drum up the men to gather wood, divide the work, give orders. Instead, teach them to yearn for the vast and endless sea. It's that passion. Developers are artists. Okay? Think of the words we use. That's a beautiful piece of code. What an elegant solution. Open Source, Inner Source is a way of developers to share their passion with others. If you want to really have Inner Source as a powerful way of redesigning how you do development in house, the first thing you need to worry about is creating a culture of passion, a personal investment in the project and in the code. So looking at some of the principles of the Apache way, let's, again, look at some of the principles behind Inner Source. And we'll see a lot of alignment inside there. As I said earlier, the biggest change and for a lot of companies, the most difficult change are the cultural aspects. A lot of companies are very, very siloed. A lot of companies don't allow for sharing, you know, across a lot of things. Culture impacts all the other principles of Inner Source. If you don't have a culture which is ready to embrace Inner Source, then you will have very, very limited success. So one of the things to think about before you even say, okay, we're going to do Inner Source and let's open up all our GitHub, you know, enterprise reposts or everyone else can share it, is make sure that you have a culture, not only among the developers, but also among the people managers, the upper management and things like that to allow that to happen. Don't not focus on the culture. And one of the ways of driving the culture, one of the ways of redefining the culture is focusing on some of the principles of communication. Again, in most normal traditional, you know, development structures, it's a team, right? And it's a force team. These are the people who are required to work on this. So the communication is just between them and no one else. In a lot of ways, open and asynchronous communication is, even if nothing else, open and asynchronous communication can be transformative inside of IT. By open, we mean that it's everyone can read it. Doesn't necessarily have to be public, of course, external, you know, public. But by open means, I don't need to receive special permission to find out what's going on with this team or why these technical decisions were made. Now, certainly, there are going to be aspects of code that are secret. You know, again, referring to Capital One, there are things that we do that are very, very highly, you know, heavily regulated. And so those are things that can't be publicly available to everyone within the company. When I'm talking about the public, I mean publicly private or privately public, whichever way you want to look at it. So there are certainly going to be things, but that is usually such a small part of what we do. It's much, much easier to make sure everything open. So you don't require special permission to see what's going on. You don't require, you know, special tools or things like that. You know, oh, we're just using HIP, HIPChat. Everybody else is using Slack. Oh, I got to install something else. Okay. Make it as easy as low burdensome as possible for people to see what's going on inside your project. Asynchronous is another really, really important thing, and especially if you're a company who has bought in heavily on agile with a big A. The main thing behind that, face-to-face communication, everyone who needs to make a decision on a project is sitting right there at the same time. That really disenfranchises huge parts of the company that could be providing insight and impact on what you're doing on. So even though, you know, HIPChat and Slack and even IRC are beneficial and they certainly have their place, and I'm certainly not saying, you know, get away from them, rely much more if you can on mailing lists. I know it's old school. I know it's gray beard. I know it's really, really old and kind of embarrassing, but it really provides a lot of ways for people who have no idea at all what a project is doing or what a code base is doing or where decisions are being made or how decisions are being made to look it up, archive it. So use things to document what has been made, but use something which is open and asynchronous and archivable to maintain that tribal knowledge, to itself document that tribal knowledge, which is really, really important to maintain a community that just doesn't live and grow by the people who are there right now. I mean, think how difficult it is, you know, a lot of times to just bring new employees on board. I mean, you know, it's such a waste of time in a lot of cases because there's so many things they need to know. Well, first of all, if they have something they can easily reference, it makes their job easier, it also helps them move around inside the company, which is very, very important for employee satisfaction. It also helps them contribute back to other aspects and other projects inside the community if everyone's operating under the kind of like the same kind of rules. So communication is very, very important. It also can be very, very scary. All right. Any questions so far? Everybody good? Cool. Transparency is also very, very different. And I think one of the one of the best ways of thinking about transparency is open and public means that you can see a restaurant's recipes. Transparency means that you can look inside the kitchen when they're cooking. Very, very different thing. This really lets you see exactly what's going on. We're going to be very transparent about our decision-making processes. We're going to make sure that people are able to see exactly what's going on. And it's only by really having transparency that you can really enable reuse. If people can't find what's out there, if it's not transparent on what the aspects of this particular project are supposed to do, then chances are very good people won't be able to reuse it because they won't know all the ins and outs of it. They won't know the dirty little development knickknacks that have gone into making it operate this particular way. Another thing is by having things incredibly transparent, you've got the multiple eye syndrome. More people are able to look at the software project. More people are able to look at the code. You're going to get better security, better constructed software. It just results in the kind of things that we normally recognize in the open source world. Another very, very important thing is the second to the last bucket is that you really can't measure what you can't see. Lack of transparency can hide a lot of nastiness, a lot of inefficiencies that are going inside your development, can also expose a lot of really, really fantastic successes. And when you first start getting into inner source, one of the biggest things that people are going to be interested in and concerned about is how do I know if I'm being successful? How do I know that my inner source efforts are realizing the efficiencies you want? Well, if you don't have an environment set up for transparency in the first place, then you're not going to be able to measure that. It's a self-defeating purpose. You just simply won't get that. So the idea that transparency is not something to be scared of. It's not something to avoid. That transparency is something to be embraced. Again, you can see how in a lot of cultures that would be very, very tricky. That's a major change. But it also needs to be something that to really benefit from inner source. There needs to be aspects of transparency. And again, this is not an all or nothing. The reason why I try to focus on the principles behind the reasoning behind that is because when you start bringing inner source in-house, you can start figuring out, okay, this level of transparency is good enough for this particular area. Okay, using this technique to ensure transparency works for this team but not for that team. So you can pick and choose. Okay, don't feel as if a failure, for lack of a term, to fully embrace all aspects of this means that you can't leverage inner source. These are just sort of like the wish list of how everything else is great. But think again about the reasons behind transparency and then focus on how can we implement this? How can we reinforce this culture inside of our community? Collaboration is another obvious thing about inner sourcing. With inner source, you want to enable other teams outside of that silo to contribute back, to collaborate back. And again, you can see how things like email lists and stuff like that foster the sense of collaboration. But it also means that you're creating an environment where they now share a common vision, common goals, common tools. There is this sense of we are not just a separate team working on a separate project, we really are a organization marching in a very, very similar direction. And I see where my part fits in. I also see how I can help other aspects where my natural talents or my natural inclinations would be helpful to prove in that side there. So collaboration is all about creating this environment where they feel again, sorry for the buzzwords, but they really are applicable. They feel empowered to be able to work with other teams. And also they realize that by collaborating with others, they really are going to be respected and rewarded inside of that. Now, some of the techniques behind this, and I really, really like these, is that too many cases, it's very, very difficult, both the open source projects and especially projects which are inside inner source, for new people to come on board. They can go and make a pull request very, very easy. But how do I know that what I want to contribute doesn't break your builds, break your environment? So what I'd like to do is say, if you're an internal project who wants to get inner source, take some time and resources to create build and test tools. Make sure that magic is no longer magic. So that way when there are people who are ready to contribute, they've already built the software for themselves. They've already tested it to make sure there's no regressions on what your expected behavior of the software is, but what their expected software is. Again, too many developers nowadays short shift that, or say building and testing, that's somebody else's problem. That really means that no one can really contribute back because you can't QA something that isn't even part in the official code base anymore. So stress making the kind of build and test tools. Another way of doing it is that, and you see this a lot on open source projects, is that look for the low hanging fruit. If there are issues inside your inner source project, that would be relatively easy for new people to come on board and get their feet wet as it were. Tag those as newbie issues or low hanging fruit or something like that. So people can really, really quickly and easily go, oh, okay, well this looks like something that might not be too difficult. It's got some real merit. I'll work on this, and especially good if there's somebody who's a mentor, you know, we'll talk about, you know, merit and things like that a little bit later on, a mentor, but somebody who would be available to help them out. Again, you're creating a culture here, an environment in a community, and those things really, really help out. So the whole idea behind it is to create this sense of community inside there. You know, community breeds loyalty. You know, it really has significant impacts for employee retention as well as employee hiring. If people can move from the environment where they, you know, really enjoy contributing to open source, and they can move into a company environment, which those sort of like, what's important to you, the culture behind that is the same, they want to make that transmission. They want to work for a company that gets it. They want to work for a company that appreciates what they do and doesn't stifle them, put them in a silo, and says you can't work on anything else unless you decide to, you know, relocate or, okay, well you're not with this team anymore, you want to move to somebody else. So it really has a large impact in maintaining really, really good developers, as the other thing as well is not only are you retaining people, but you're retaining the kind of people that you want to retain. Really, really energized, engaged, talented developers. You know, everyone has something they focus on, but then that itch gets you, and you want to work on something else. And if you can provide an opportunity for them to scratch that itch inside your company, they're going to stay, and they're going to really put forth as much as they can. So really, focus on the whole idea of a community. There are aspects of measuring the health, but also keep this thing going. It's not a done deal. Okay, we've got a community. You've got to keep on working at it. And finally, there's the whole idea of meritocracy. And this really goes into great when you start talking about people managers and middle managers why this makes sense. Because the idea is that you're best employees, your best contributors will bubble up. It'll be apparent who they are. Okay, not only is that great because it provides them the incentive for bonuses, promotions, and things like that, but it also provides you the opportunity to leverage their talents in mentoring other people. Okay, the people who bubble up with high merit are also the kind of people that in general people want to emulate. And so provide them the opportunities to do that inside webinars and tech talks. Allow them to go to conferences and things like that. These are sort of like the intangible but intrinsic aspects of gaining merit. You have to have some sort of merit level inside your company to really engage in their source. Because at the end of the day, people will say, well, what's it for me? What's the path? What will I gain by contributing back, by doing more than I should? Yeah, I like scratching the itch. But at the end of the day, this is also work. And managers will say, what good is them working on something else? I want them focused right here. So having a merit structure, a rewarded known company wide merit structure helps alleviate both of those concerns. Because now managers and developers can see the benefits of engaging, truly engaging in their source projects inside the community out there. So make sure those rewards, those potentials are well known. And finally, some initial final thoughts about it. A community is not the same as a team. And that's a really, really important point. A team is something which is assigned. A community is something which is self aware, self acknowledging. We are a community. I'm part of a team. We are a community. Again, it draws back to the idea that what we're trying to do is create a culture inside of it. And so the cultural has to be one of a community rather than a team. It is self organized. It is self identifying. It goes back to that quote about the ship. You don't need to tell them what to do. There will be 10 steps ahead of you knowing what they do because their passion is in getting this project, this code base, this deliverable out and ready. Contribution is work. It really is work and it needs to be rewarded and acknowledged as such by managers but also with fellow employees and things like that. Another thing is that intersource is not something that you can just say, okay, we're doing intersource, bum, we're done. We're going to implement all this stuff. It does take time and resources and effort to create an environment where all these things happen. If you think of a garden, yeah, you can most probably take a plot of soil and throw some seeds down and you might get some seeds out there. But you have much better luck if you tend the soil first. If you actually do something to prep the soil, the garden for what it is we're trying to grow. And so really you'll need to be able to do that. I mentioned one which is the idea that you're going to need to have build and test tools available which you may not have or may not be accessible to the people that you want them to be able to have access to that. So that would be something you would need to change. So don't think that this is something that you can just wave a wand and do. It will take some time and resources. And again, I encourage people that if you are interested in doing this, join the intersource commons. Because we're all doing this. We've all been in various stages of doing this. We can help people with what works and what doesn't work. What's also nice about the intersource commons is that we operate under what's called Chatham House Rules, which basically means you get to share information, but you can't assign that information to any particular person or company. So it provides some anonymity inside there. So you don't have to worry about sense of information leaking out or, oh, this is how FUBAR is doing it. So it's very, very private, but it's a great way of sharing information. And another thing, and this is really, really important, one of the things that I've really had been working with Capital One about and they're really, really getting it, is the idea that transparency is not a threat. Again, old culture is very, very much about, wow, we need to really limit the amount of information that our employees see, the other teams see, and things like that. Because there is that sense of, okay, this is our stuff. I don't want anybody else messing around with it. Or what happens if somebody else starts working around with it, am I going to lose a job? That kind of stuff is really, really scary. The best thing to get rid of that is being very transparent of what's going to happen. Nobody's losing a job. What we're doing is making the best way and the best use of people's talents and things like that. That's it for actually my talk. This is some contact information for me. I wanted to thank Phil Steyt, so I thought it was going to like being here. He provided some insight on the principles of inner sourcing as well. My slides are always going to be uploaded. They're going to be up there on SlideShare. If you need to contact me for any reason, I'll be here for the rest of the conference. That's my contact information as well. Anything I can do to help, just let me know. Like I said, Inner Source Commons is a great resource. This is something that I've been driving a lot inside of Capital One. I see this as like the long tail of open source. This is like the final result of the open source revolution. We've got the external world doing it. Let's bring this stuff in-house. It really continued the energy that really drove open source by having companies really embrace it. Not only by leveraging and consuming and being good open source community members, but actually practicing it in-house. Thank you. Any questions? We have a couple minutes. Yes? Okay. The question was, what kind of projects do I push to be Inner Source in our company? First of all, I don't try to push anything. It's got to be something that people willingly want to do. If there are pushbacks between- if there are projects that do not want to be Inner Source, you can't whip some Inner Source on them. It's just not going to succeed. It's not going to happen. For me, I try to find projects which are as generic as possible that would have as wide range of potential contributors as possible. The things like libraries, frameworks, messaging systems, the kind of things that everybody needs a part of and everybody's doing. Everybody's recreating it here. Everybody's recreating it there. It's much better to try to use those places to consolidate things. A good thing would take an inventory of what your teams are doing. Look at where places could be shared. There are a lot of companies now who actually have a shared mantra that needs to be once particular space. But look at places where you're seeing a lot of places that there could be reused, but isn't reused, or places where they're talking about reuse, but they're not really letting anyone contribute back. That's another- that's a great place to really start throwing some Inner Source inside there. There are a lot of projects which- we're a shared library. We provide it for you. Yeah, I knew this feature. We'll code it for you. That really doesn't work out well. It doesn't scale well either. There's always that miscommunication between what they want and what actually gets delivered. It's so much better, so much more efficient. It just works so much better to actually give them the permission to contribute code, but also provide the tools they need to be able to ensure that what they're doing is breaking things, works for their environment, and stuff like that. Yes. The question was, if you have contractors involved, does that change the complexion of things? It really, really doesn't. The other- one of the things you need to worry about is make sure that whatever agreement you have between the contractors is okay, because chances are good. Another thing that I could have mentioned is that a lot of businesses, before they open source a project, they intersource them. They actually start working and developing the project in an intersource fashion, so when it's time for them to open source it, they already have the culture down. They already know how to work with the community, because they've been working with an open source community already. It's just been inside the company, and now you're embracing a larger company out there. In that way, you also need to worry about if there's a possibility that whatever is being contributed by a contractor can be open source. But in general, I think it really, again, makes the contractor's job easier, because what you're trying to do is get away from this us versus them mentality. Okay, we're the team behind it, and you're the helper. You're the contractor. You're something like that. You know, that doesn't work. That's what you're trying to break down. And so if you have an intersource environment, you're not seen as somebody external. You're seen as somebody who's really contributing back and collaborating with the team, rather than just somebody who's doing work and throwing stuff in their lap. So it makes your job a lot easier. Yes? Right. Yeah, the question and the point was that there are some crafty, ugly kind of stuff that you just have to do, because it's a job. It's work. And that expecting people would just naturally whistling gravitate towards doing something which is ugly and stupid work. At the end of the day, it's still business, right? I mean, you still have teams that are required to create something. And they're not going to be maybe as happy to do that. But if they know that they also have the opportunity to sort of like cleanse the palette with intersource projects, they'll be much more happy to be able to do that sort of like, you know, grunt work that nobody needs to do. It provides that opportunity, you know, to to get around that. So they're not as bored as they would normally be. Yes? The question was, what do you look at since the transparency is so important? What do you look at? That's a great question. That is actually something that the intersource community is presently kind of, I wouldn't say struggling with, but we're trying to come up with what exactly those things are. You know, there are of course the simple metrics as far as, you know, contributions from outside, you know, outside teams, outside, you know, groups and things like that, which provides some insight to that. But as with all things, it can be gained very, very easily, you know. So if the, it depends on what you want. So, yeah, I'm kind of like, you know, going about 150 right now up there. So it is a problem. It is not a problem. No, it's not a problem. It's something that we are working at trying to help define. And there are certain metrics that work in some situations and some environments that don't. Again, I think the easiest and quickest answer would be, is that's the kind of stuff that we're trying to come up with at the intersource commons, is to come up with sort of like a mutual agreement, mutual methodology of how to really gauge intersource success in a transparent environment inside there. You know, there are the normal metrics, but you really want something with a little bit more meat behind it to really help engage. We're really, really early on in this transition. So those kinds of things are things that we will define, you know, as time goes on, is where people, you know, come to the forefront and start engaging intersource, then it sort of like the, it'll become apparent what real ways of doing that are. Sure. Yeah, the question was, are things like employee retention, employee happiness, good metrics? Certainly, Capital One, that's what we've been looking at, is that, you know, are we able to obtain the kind of talent that we want to obtain? Are we able to keep the amount of talent that we are? Capital One is a very, very young company, as far as moving into the IT space. We've only really been, you know, hiring developers and engineers for maybe the last three plus years or so. And so it's right around that time that developers get itchy, you know? And so we're looking at those numbers, you know, engaging our success on, admittedly, our very early entry into intersource. But those are some very, very good metrics. You know, looking at developer happiness, looking at, you know, if you're seeing, you know, the individual contributor community inside your company, kind of like self-organizing, if they on their own decide, you know what? We need to, you know, talk more and have more opportunities for webinars and sharing information and stuff like that. That also is some intangible inferences that definitely mean that it's becoming a success. So at present right now, it's more of those kinds of things. It's more of those gut feelings tempered by we're not losing people. We're gaining great people. Those people are, you know, are asking their friends to also come on board. That really helps show that it's succeeding. Anything else? No? Oh, yes. Three times. No problem. Right. Yeah, it was a long question. I don't think I can repeat it. But basically it says that in the open source community, you have a lot more freedom and flexibility than you do as an employee, as far as like voting with your feet, running off, I'm going to do something else, whereas you really can't do that much at work. What you will find and what I've seen in a number of companies is that when the community itself of developers feel as if their happiness and their collaboration and their ability to collaborate is being threatened by a poisonous person or something different, management is aware of that very, very quickly, certainly much more quickly than it would ever be if there wasn't that transparency. Because not only is that a person being a pain for that particular team, but because there is this level of transparency, lots of people are knowing that he or she are being a pain. And so it actually addresses that situation. There might be times, of course, where the company decides, you know what, yep, they're a poisonous person, but she is a fantastic coder and developer. We can't get rid of her. But at least you will have a community support system built around you, you know, the developer as well as incoming people, to help alleviate that at some level, much more so than you would be otherwise. So it's a, you know, it's a possibility that could never go away, but still the community aspects will help out quite a bit, I think. Great questions, by the way. Thank you, everyone. Well, as I said before, these slides are going to be up on Slide Share, so be sure to download them. Enjoy the rest of the conference. I will be around. Thank you for your apt attention, especially after lunch. Everyone stayed awake. Thank you very, very much. Enjoy it.