So I'm gonna be talking about localization, right? So localization has been quite a big headache ever since I started working for Linux Foundation 11 years ago. So my interest is how we can make more people work on localization with a lot of joy and with a lot of productivity. So that's the goal of my activity related to localization. So this is the key topics of this talk, right? So one of the things I would like to touch upon is how technology can actually solve issue with localization, right? So localization has been largely manual work but by taking advantage of technology so we can actually make it easier and probably more fun. So that's one thing I'd like to talk about. And the other is, okay, then if we take advantage of technology so what are the tools, technology tools that we can take advantage of? So that's the other thing I'd like to touch upon during this presentation. And the other thing probably the most important thing is how we can make the localization work more fun and productive. So those are the three things I'd like to talk during my presentation. So as I mentioned earlier, localization is a big headache for local open source communities. So the impact of the language barrier to the industry in non-English speaking country is actually huge. And this is particularly true, unfortunately, in Japan because Japanese people's English proficiency is one of the lowest in Asia, ranked 53rd in the world. And without localization, the new technology originated overseas will not be spread in non-English speaking countries, again, like in Japan. So we need a localization for local community to catch up with the latest technology trends overseas. And it is impossible to make everyone to become able to communicate, reading and communicating in English language, but it is possible to localize more documents and localize a lot faster those documents by taking advantage of technologies. So localization is a big headache, but I would like to solve this problem with technologies and community. So in order to solve this technology, in order to tackle this issue, I would like to, first of all, understand what is the localization work? So localization work is actually made up by two elements. One is translation, the other is interpretation. So translation is a relatively lower value at work because this requires only language skill, whereas interpretation requires several elements. Specific technology background or technology, technical knowledge to be able to, for example, if a new technical term were created in English, then the people who does the interpretation work will have to understand what is that technologies and what would be the best interpretation with terminology that can be used in, for example, in Japanese language. So this is actually a really high value at work, but today localization work, localization work, both interpretation and translation largely manual work by human. But in the future, among the interpretation and translation in between interpretation and translation, this lower value at work translation, it can be replaced by machine, the technology while interpretation will remain in the human work because this requires a very specific technology or industry skill or knowledge. So in order to make localization work more productive and fun, we need an open and common platform for open source communities. So to be more specific, we would like to, we need a tool, we need a common platform to make the translation part, not interpretation part, translation part to be done by machine or tools. So my hope is that we'd like to get our force together to build a common platform to automate the translation part. So what we need in order to make that happen, what are the requirements? So I'm thinking these three are the key requirements to make that happen. One is everyone to use the tool to translate and share the translation memory. This is the important part. Not only just to do the translation, but share the translation memory. That's the one thing that is important. The second part is trained machine translation engine that is optimized for open source industry, right? So there are machine translation engine out there, probably not many people actually use it, but in order for us to be able to efficiently use the engine, the engine will have to be optimized for open source industry usage. And third, and again, this is the most important part, build the mindset and process that the translation will have to be done by the community. And no, never do it at all. This is important part. And share the result together with the community. So those are the three things that has to happen for the localization work to become more fun and more productive. So what is the, I mentioned that everyone use the testing to translate and share the translation memory, right? I said, share the translation memory is quite important. What is the translation memory and why it matters? So translation memory is basically a database of translated words. And it can be a sentence or paragraphs or a sentence like units, like heading these titles, elements in the list that have previously been translated in order to previously translated. So this is basically the translation memory. And one good news is that, there is an industry standard file format for the translation memory exchange TMX file format. And so people are actually able to generate the translation memory with the standard file format and actually share the memory and make the translation memory better by collaborating. And also, regardless of the tool people use, they can actually generate the same translation memory and share it. So that's one good news. And the benefit of using translation memories, there are several memories, several benefits. So one is the translation tool will translate the same sentence words or sentence like units automatically and able to avoid from translating those sentences words and sentence like unit over and over. So this is actually a big benefit. And actually by doing that, specific terminologies will be translated into the same local language. So this is actually important. For example, English words with a container, maybe translated, person A might be a translate into one way, but a person B might translate into the other way. But if the community got together and use the same translation memory, then this issue actually be solved, right? Container is a container. There is only one single translation interpretation everyone using within the community. And also, we can, by using the translation memory, it's actually a similar thing, but we can actually set the rule by the translation rules by the community. So community might use one terminology. They would like to keep that terminology as in English, right? And maybe some other terminology needs to be translated into Japanese, but, you know, so community can set the rule that this term stays in English, this term we translate it, something like that. No, the community can set the rules by using the translation memory. So this is the big benefit of using the, these are the big benefits using translation memory. So it actually matters a lot. So what to do with the translation memories? So this is what I'm thinking the ideal process of using it. You know, first of all, get the translation memories from the community every repository. Then, by using the translation memory, walk on the translation. And the person will create a new translation. So share that new translation memory with the community. And then, you know, merge the new translation memory with the existing translation memory and update the community translation memory in the repository and not keeping this cycle, right? And by repeating this process over and over, the community will get more and more translation memories and less and less duplicated translation. So this is the ideal process. So let me touch upon some of the available translation tools. So one of the tools that's widely used is Omega T. This is an open source translation tools that anyone can actually download and use. And I mentioned that, you know, there's a standard translation memory file format, PMX. But there are actually several other file formats. And Omega T is compatible to many variety of file formats, like TTX, TMXL, and others. And also, Omega T is able to translate over 30 documents formats, such as Microsoft Word, Excel, PPT, STBL, and others. And of course, an open document format. And also, one of the good things about this Omega T is it has got an interface with popular machine translation engine, such as Google and DPL. So when you use Omega T, use the community translation memory is one thing. And the other thing you can take advantage of is use the machine translation engine, such as Google and DPL. And also, one good point about, you know, one benefit of using Omega T is that the tool works well for group work. So if you would like to use a tool of the community translation, Omega T is actually a one good option that is suitable for the nature of the collaborative work. But one downside of that tool is actually, this is actually not an easy tool to learn and use. This is actually one downside that Omega T has, but this is really a great tool. And, you know, at Linux Foundation in Japan, obviously, we have been using Omega T a lot over the past several years. And the other available tool is a Texture Transvation Editor. So this is actually an online tool provided by a national institution of information and communications technology. We call it, they call it NICT. This is the Japanese government, Japanese funded research institute. And this Texture Translation Editor is not an open source tool, but anyone can use it for free. And the license term is actually very clear for open source usage. So what it means is, if you use, you know, like a popular translation engine. By the way, so this Texture Translation Editor, if there is a, this is the editor that you can see, you know, you can see a graphic on the right. This is the editor. But behind this, there is a translation engine, Texture Translation Engine, right? So this is a machine translation tool. So if you use other machine translation tool, then you might run into an issue, like, you know, what is, you know, if I use, who is the owner of the outcome on the translation, right? So machine translation, you know, you actually are not the one who actually do the translation. Actually, machine did it. So in that case, who owns it? No, is it free? Is it, you know, is it okay to share the outcome of the translation with anyone, right? So this is actually not too clear if you use many of the translation engine. But this Texture is actually really clear that, you know, we can actually use it for an open source project and share the outcome of the machine translation for free. So that's one thing. And once again, this Texture is taking advantage of machine translation engine. And one good thing about this is no need to install a software on your PC. So this is actually quite easy. And just like Omega T, it is capable to translate many different file formats like Omega T. And one good thing about, you know, this Texture is capable to use a wish wake mode. So this is something not available with the Omega T. And one, I personally feel, you know, one of the biggest benefit of using Texture is automatically merge the translation memory in engine and get trained if everyone use this. And also capable to generate a grocery from the translation memory. But, you know, however, one downside, one issue is, you know, in terms of group translation work, this is not the best solution at this moment. So that's the one downside. So I brought one of the cases study where actually a community got together and use the tools and work on, try to build a process of the community translation, which is the Hyperlaser Japanese Documentation Working Group. So they, you know, they are the group of the translator and who work on the Hyperlaser fabric documentation localization. And the group, you know, the group is using the GitHub to collaboratively translate the documentation. And also the group also partly use the translation memory, which is maintained on the GitHub. However, this is the issue. However, they are still facing difficulty to update the translation memory by aggregating feedbacks from the community translator and merge them to update the existing translation memory.  So, and the reason why this happened is because today it is simply not easy to share a translation memory and maintain at one location. So, although this Hyperlaser Japanese documentation working group is trying to do the way, the way I described in the earlier slide, but they are facing actually running into the issue of actually doing it because it is actually hard to actually, you know, it's actually share the translator, generate the translation and share it and maintain it. So we are going to make one step forward to remove that needle of localization community. So we identify that this is the issue, right? So it's difficult to, you know, although it's important to share the translation memory, but it is not easy. So this is a needle, right? Of the localization community. So I would like to do something about it. We are going to make one step forward to do that. So today I'd like to make one announcement about NICT. I mentioned earlier that who actually developed the TXTRA translation engine. And the Linux function will collaborate on TXTRA, right? So by using the tool, by using the community translation, we should be able to get a lot better productivity, obviously. So with a machine translation engine optimized for open source usage, the productivity can become much higher. So this is one thing, you know, NICT and the Linux function in Japan actually like to achieve, make the, create the, the translation engine that's optimized for open source usage. So to do that, you know, NICT and the Linux foundation has reached agreement to work together to train TXTRA machine translation engine to optimize it for open source community use. So that's the agreement and this is the announcement today. And moving forward, what we are going to do is the Linux foundation will host TXTRA at the Linux foundation server and which will be opened up for the local open source user community to use. And also NICT and the Linux foundation will collaborate to tackle, to add the group work feature to TXTRA. As I mentioned that, you know, TXTRA is weak at, you know, group work functionality. So we are going to, we are going to try to add that group work feature to TXTRA. So community can easily share the translation memory and also build an ecosystem around the machine translation such as a commercial tool or open source tools for CMS, you know, content management system, like, you know, WordPress-related tools or and also get repository for instant messaging social, I mean, instant messaging or social medias and so on. So together with the NICT and NICT, the Linux foundation, we try to solve the needle, maybe solve the issue of issue with the difficulty of sharing the translation memories within the community. So the value of using optimized machine translation engine is like this, right? So as I mentioned, it is difficult to actually generate the translation memory and share it and merge with the existing one.  But with machine translation, these steps can be automated because translation engine can take care of, you know, basically, you know, sharing the translation memory and merging with the existing one and updating it. This is done by machine translation, machine translation engine automatically. So this way, we can actually solve issue we faced with the Hyperledger, Hyperledger Japanese Documentation Workgroup, right? They had, they faced the difficulty of sharing it, but no, it will be automated with the machine translation engine. And finally, this is my final point. After all, people matters most. You know, we work on the tools, we work on the translation engine, but after all, people actually matters most, you know, to be able to make the localization work fun and productive, right? So one of the things that we have to do is build a mindset and the process to share the translation result and memory. So mindset is basically, you know, localization work as fun, collaborative work. It's not like, no, something people do it alone, you know, alone by themselves, right? And also a common repository, not only for the localization outcome, but we have to share the translation as well. And also a work process. It would be good to have maintainers, commiters and reviewer and sign off by process. Just like, no, we have, you know, just like we have for developing open source software. So this is, you know, this is the one thing we have to do. And also, you know, community localization can become more fun, because learning through the localization. Now we are able to learn new things, like, you know, many of the technology created in English language. But, you know, the people who actually do the localization is actually, you know, the people who are actually learning earlier than anyone else. So this is one good benefit translator will have. And also by, you know, taking advantage of open source way of translating, the translation will become collaboration with others, not in a standalone project. So we can get feedback to the work and we get a higher reputation and we get an appreciation for the community. So this is one good benefit translator can get if we do it in a community way. And if we take, you know, we are able to take advantage of technology, we can actually not eventually focus on high value edit work, you know, interpretation part, rather than, you know, you know, translation part. Because the translation part will be taken care by the machine. So, you know, people can focus on interpretation of new technology, you know, understanding the context of new technology and create the appropriate world for the local language. So this is actually a fun part. So these are the things, you know, we have to promote and we have to make people understand, you know, that for localization work to become more fun and productive. So if you're interested in please join us, we have the collaborative translation meetup in Japanese language. This is linked to the meetup.com we host. Since, you know, due to the COVID-19, we have not done the meetings last nearly a year or so, but I am certainly hope to re-energize this community. And also if you would like to know more about the status of, you know, this activity, please reach me out at my Twitter account at Nori underscore Fukuya-su. And one final word that I would like to leave you with. The Universal Community Translators Unite and share the translation memory. Thank you. And if you have any questions, please let me know. If you have any questions, you can tap in in the chat windows so I can answer the question. So in the chat window, Miura-san, Hiroshi Miura-san has been adding some comments. Actually, Miura-san has been working to connect Omega-T with the textual translation engine. So my hope is, no, no, we can connect, we can use, we can still use Omega-T and use the translation, textual translation engine. He actually mentioned that in the chat window. Any questions? I guess now I can conclude my talk. And if you have, once again, thank you for joining my session. And if you have any questions, please reach me out at my Twitter account or participate to our collaborative translation meetups. There's one question. Does textual agreement is not only for Japanese English or other language? Yes, it is. It doesn't specify for Japanese language. Any other questions? Okay, thank you so much for joining. And I am looking forward to hearing your feedback somehow, and I'm looking forward, I want to join our community. And also, I really hope that you will enjoy the rest of the event. Thank you so much. All right.


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?  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.  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?  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 no one behind it. We had basically hooked our cart onto the NCSA web server and it was driverless.  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.  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.  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.  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.  At the end of the day, it's still business, right?  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.  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.  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.