Driving Innovation with Innersouce

Faten Healy at UXDX Community: Australia. Video: https://youtu.be/GT445CbSac8

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Introduction and agenda

[00:00:00] Driving innovation with inner source. My name is Faten Healy. I'm very happy and super excited to be part of the first UXDX community event in Australia. I'm a solutions engineer at GitHub based in Sydney. Developers work with designers to build products, salespeople sell the product, and we as solutions engineers bridge the gap between these two teams. This is my Octocat. She loves coffee as much as I do. If you like my Octocat, you can build your own too. Just go to myoctocat.com and have some fun.

[00:00:35] This is our agenda for today. We cannot talk about inner source without a short section about open source first. Then inner source: the what, why and how, with a few examples from real customer stories. And then we'll wrap up with a section called what's in it for me.

Open source

[00:00:54] Let's get started with open source. Let's start by defining open source software. It's a type of computer software in which the source code is released under a permissive license, allowing users the right to use, study, change and distribute the software to anyone and for any purpose. The next question is, why open source software?

[00:01:23] From the software composition report, you know that today 99% of organizations are leveraging open source software, and 80 to 90% of new modern application development consists of open source software, regardless of the programming language or technology stack. When you're building a new application, only a small percentage of your code comes from your own in-house code. The rest comes from the open source libraries you're taking in as dependencies. And that's a good thing. It means you don't have to implement a library for sorting a list or executing mathematical operations. The rest, the 10%, represents your own IP, your own intellectual property, and this is what differentiates you from others. This is the truly unique code that your developers are writing in-house.

[00:02:19] Where do most open source projects live? On GitHub. GitHub is the go-to platform when we talk about open source software. As you know, GitHub has over 50 million monthly active developers, maintainers and enterprise users. Anybody looking to consume or contribute to open source is on GitHub. GitHub is truly the home of open source, and there are more than 128 million projects on GitHub to choose from. If we check the top open source projects, number one is Microsoft Visual Studio Code, with over 19k, followed by the Azure documentation. Then you've got Flutter by Google, for cross-platform app development on Android, iOS and others, and at number five you've got TensorFlow for machine learning, with close to 10k.

What inner source is and the problems it addresses

[00:03:11] Now we get to the inner source section. This is an exciting section dedicated to enterprises. We spoke about open source; now let's start with inner source, beginning with a definition. What is inner source? Inner source takes the lessons learned from developing open source software and applies them to the way companies develop software internally, inside their organization. In other words, it's the application of open source principles within your organization. You could say the projects are internally open source, and you want people to discover and contribute to those projects like they do on github.com today.

[00:03:59] That's what inner source is. But what problems are people facing? What are they trying to solve that's making inner source so popular? What are the common enterprise and open source challenges? First of all, if we look at the average enterprise, most people struggle with communication across divisions, and even between teams in the same department. There's often a lack of understanding in teams around the open source style or workflow and how to use it, and sometimes it's probably a lack of experience in using pull requests. Lots of organizations struggle with communication and awareness of existing development within the same organization.

[00:04:45] We also have a different type of challenge inside some organizations, where people have code ownership. That means when it comes to their code, they don't think of themselves as the maintainer of the code. They think about it like: it's my code, it's my team's code, my department owns this code. But in reality, it's owned by the entire organization, and you are only the maintainer. You are looking after that code to make sure only good code makes it to production.

[00:05:17] Here is a list of the common pain points that we've seen when it comes to inner source. This is not the whole list, but some of the painful ones. The first one is multiple version control systems: different systems in place that don't integrate and don't talk to each other. This is one of the first blockers to collaboration, the tools you're using inside your organization. Code and metadata are not searchable. On top of the struggle of knowing what's being developed, closely followed is: where's the code, how do I get access to it, why is there no documentation here?

[00:05:58] Organizational knowledge sharing: how are handoffs facilitated as people join or leave organizations or different teams? How is the tribal knowledge of legacy systems preserved? Documentation, if it exists, might be in another system apart from the code, which is also sometimes not very searchable. Organizational distance: how do developers find one another, how do they work with one another, how do they help one another? Organizational distance always leads to more and more bugs, as per a Microsoft study.

Inner source principles

[00:06:40] Now that we've spoken about the pain points, let's dig a bit more into the inner source principles. First, open culture: creating a level playing field for the open sharing of work, ideas and feedback, and ensuring cultural and strategic alignment, because open collaboration encourages more contribution. It's the same way it works for an open source project, where you can accept changes from anybody in the world, and that's a lot of brain power for one single project. In the same way, inner source requires a culture shift. Your team's culture will need to encourage knowledge sharing and welcome contributions from across your organization.

[00:07:24] Transparency: ensure that the process as well as the product itself is visible. This can be achieved by decoupling communication from time and space. Opening up the project is not enough. Inner source is not just the code becoming visible, but also the process and the decision-making behind it.

[00:07:46] Discoverability: sharing work and making it easy for others to discover, use and contribute to your code. Developers don't always have to start from scratch, and inner source helps your team discover, customize and reuse existing internal projects. People from another department can use an internal project you have built, build other things based on it, or maybe modify it a little so it suits their own specific needs. Innovation: inner source is an amazing conduit for learning, exchanging ideas and facilitating innovation. Inner source brings more ideas to the table, and teams can more easily innovate in that scenario.

Inner source goals

[00:08:34] That leads us to the inner source goals section, where we'll talk about solutions, the how. First, reuse: encourage the natural desire to contribute to other code, in the open source sense, the satisfaction users get from contributing to other projects. Celebrate collaboration. Breaking silos: I know silos won't always go away, as sometimes things need to be private, but all of us sometimes have to challenge this if we want to achieve our goals. Community: in the same way we've seen open source communities, try to build your own community inside your organization. All of that will lead to better software, faster. Better, because you'll have more people, more eyes, checking the code. And you can build faster, because you might get code suggestions from members outside your team.

Tips for an inner source culture

[00:09:36] We now understand some of the problems, and we've discussed what inner source sets out to achieve. How do we get there? Let's talk about some tips and tricks for implementing an inner source culture. Driving innovation through customer focus, fast iteration, open communication, grassroots ideas, low-risk experimentation, security-centered development and operations, and adoption of an inner source culture.

[00:10:01] Innovation from all directions: that means being open to ideas from all different departments and all different teams. When everyone can see what you're building, they get an idea, and they can go and experiment in their own safe experiment environment, maybe in their own branch, without affecting the main production code, and then give you suggestions in the form of a pull request, for example.

[00:10:28] A shift-left mindset, which can be applied from a few different angles. Shift left from a security perspective, where you run code scanning and security scanning once developers push code, at the pull request level. At the same time as we want to be open to all these innovative ideas, you want to make sure you're doing all of that under the security and compliance umbrella. Shift left in the DevOps concept, where you're automatically running your tests and automated workflows with CI/CD. Sharing: we've spoken about that a few times now, being open about your project, sharing your code and welcoming anyone who would like to contribute back to your code.

Rachel's idea: if it doesn't have a URL, it didn't happen

[00:11:16] Let's take an example. Please meet Rachel. She's a new software engineer, very ambitious, and on her first day, or maybe her first week at work, she came up with an idea. It might be a great idea, it might not be, but the point here is that she's sharing her idea with her team. And the response she got was, "We tried that before and it didn't work." Okay. This is a great example of how, first of all, she's not learning from previous developers' experience, and this is how a discussion gets totally killed, totally stopped. It goes nowhere from here. And maybe next time Rachel has a really new and unique idea, she might not even share it with the team.

[00:12:02] Let's take a step back and consider the same scenario. Rachel shares her idea with the team, and she gets the same response from another senior developer: "We tried that before and it didn't work." But this time the difference is that she gets an issue thread or a pull request thread where she can read the whole conversation and understand the reasoning behind it. Sometimes things change, and what was bad at that time might be a good idea now. You can see it's an open space where she can share her opinion in that thread as well. That's the way she can learn from other experienced developers, and that will make her a better asset for the company later on.

[00:12:44] We have a saying at GitHub: if it doesn't have a URL, it didn't happen. Internally at GitHub, GitHub is used by all different teams, from marketing to support to sales. Everyone will create an issue or a pull request if they want to make a change.

The contribution funnel

[00:13:02] Another way to think about any project community is through what we call a contribution funnel. The top of the funnel consists of the consumers, or users, the ones who are using your project. They might make a copy, fork the code, or use it in their own project. Contributors are the ones who might contribute to the project by logging a bug, requesting a feature or adding some documentation, and they might also contribute by writing some code, some tests, building a new feature, or fixing the bug they reported. At the end of the funnel is actually becoming a maintainer. It's a position where you are actively involved in and influencing the direction of the project.

[00:13:44] When implementing inner source, we need to think about these specific users. The first one is consumers. Most people looking at your project just consume it. They might go ahead, download the software and use it, and they might not come back. If it doesn't work for them 100%, they might not even come back. And that's fine. That's what inner source is about, at least for them. It helped them. They found something, they consumed it, maybe it solved a problem for them, and that's brilliant, because that's how we can improve productivity, and that's really fantastic.

[00:14:18] A very small percentage of those consumers might come back and contribute time in some way. Your job as the maintainer of your codebase is to maximize the number of people who go from consumption to contribution. To do so, you need to make it easy for people to consume your software. You want a good README file. You want to make it easy to download and install, without too many prerequisites. You want a screenshot that shows people what they'll get when they install the software. That sort of thing maximizes the people at the top of the funnel. And then you make it easy to contribute back.

[00:15:01] A very small percentage of those people will actually contribute via code, meaning they'll write code and submit it back into your project, and this is extremely helpful. This is how you can build your internal community inside your organization. When people do contribute code back to your project, you want to be very welcoming to them. You want to make sure you're responding to their pull request, you're giving them good feedback, you have some tests running on that pull request, and you're giving them quick feedback on whether the code in that pull request will get accepted or not. That may lead, later on down the track, to them becoming maintainers. So you want to make sure you're providing people with opportunities to become maintainers and to influence the future, the product direction, of your project. That's the contribution funnel, and you want to bring more people into that funnel so you can get more and more useful contributions to the project that you're sharing internally.

Practical features: internal repositories, READMEs and templates

[00:16:08] I'm going to share a few more tips that you can benefit from when you're implementing an inner source culture. The first one is internal repositories. When possible, use internal repositories. In other words, keep your repositories open so that only users in your organization, of course, can access them. You can use internal repositories to practice inner source within your enterprise, within your organization, so members of your enterprise can collaborate using the open source methodology without having to share any of your IP, any of your intellectual property, publicly.

[00:16:48] README: every project normally has a README file, and it should be clear, simple and straightforward, as it contains the instructions on how to download, learn and deploy your project. On top of that, treat your README as a constitution, so that it's not just a set of instructions but a place to talk about your goals, your product vision and your roadmap. CONTRIBUTING.md files are also recommended for internal repositories, the same way we have them in the open source world, so you can help new contributors get started.

[00:17:30] Templates: you can make good use of all the different types of templates you have. You can create an issue template to make it easier for contributors to provide all the required information in the issue when reporting a bug or requesting a feature: the replication steps, maybe screenshots, operating system, browser, all of these details. The same concept applies to creating a pull request. You can create a pull request template to normalize communication when contributors are suggesting changes to your code, to your repository. Repository templates: anyone with admin access can make a repository a template, so users can generate new repositories from that template with the same directory structure and files [?].

[00:18:18] Discussions: this is a new feature. Discussions is a new way for software communities to collaborate within a repository, alongside issues and pull requests. So discussions, issues and pull requests all live in one place on GitHub, close to your code, close to where your code sits. Discussions are a great place for Q&A, and by using GitHub Discussions for Q&A, you can later gather this information to populate your FAQ document.

Secure automated workflows

[00:18:52] The last one is secure automated workflows. We spoke about open culture, trying to share internally as much as possible, but at the same time you want to make sure that not everyone in your organization can go ahead and delete or force push code to production, for example. So you can set some rules that help you practice inner source without messing everything up. Some of these features are protected branches, where you can enable several protected branch settings to enforce various workflows before a branch can be merged. If required status checks are enabled on the branch, you won't be able to merge changes into it until all the required CI tests pass, for example.

[00:19:37] Or required reviews, where you can specify that you want at least two people to review and approve the code before it makes it to the main branch. You can have code owners, where you specify the owners for specific types of files, for example, and as code owners they must approve the pull request before it can get merged. You can benefit from all of these, as well as GitHub Actions for CI/CD automation, and for automating any process in your software development life cycle. With GitHub Advanced Security, you can also make sure your code is scanned for security vulnerabilities at the pull request level.

Customer stories: Ford, IAG and SAP

[00:20:18] I wanted to share some examples of companies that have seen the benefit of fostering an inner source culture. Productivity, performance, time to market and cost savings are just a few of the benefits that can be achieved through inner sourcing. When your team is focused on that 10%, your unique intellectual property, through inner source you are in a strong position to accelerate innovation, increase your team's productivity and increase your competitive differentiation.

[00:20:49] Ford is a great example of how inner source eliminated an us-versus-them mentality by providing a secure environment that encourages people to collaborate and work together. Ford had a developer in their business working on speedometers who was very keen and very interested in AI. The manager for the AI project found that most of the commits to their public AI project were made by that developer, who was from outside their team. Using the GitHub data, they were able to offer that extremely talented person a job inside the AI team, making the best use of that talent. Because of this open-by-default culture, which allowed this developer to access the AI repositories, they were able to access the skills they needed from within their organization.

[00:21:46] Another great example is IAG, one of the largest insurance companies in Australia and New Zealand. Historically, developers at IAG used a variety of version control and code management tools. Some were even sending code back and forth in email attachments. Then their teams started moving to GitHub organically. Having that one version control system in place, which encourages collaboration, is the first step towards a healthy inner source environment.

[00:22:21] Recently SAP open sourced their inner source project portal so other enterprises can benefit from it. Each tile in the project portal represents an inner source project. The list of projects can be filtered by programming language or anything else, and it's searchable. You can also publish it as a private GitHub Pages site, another feature that became GA recently.

[00:22:47] The last one I want to share is not a customer story, but I wanted to share this video from UXDX a couple of months back, where my colleague Kate Simpson talked about how to be a great remote product manager. At the same time, in that video, she shared some great tips on how teams can collaborate and work together.

What's in it for me

[00:23:07] Now the big question coming to your mind is: what's in it for me? Some of you might be saying, "Ah, this is all theory. It won't work in my organization. We are far away from all of that." But let me tell you, this is a very common misconception. I gave you some customer success stories, but there's one more that I haven't shared yet, which is Microsoft. If you go back five or ten years, you would never have thought that Microsoft would have anything to do with inner source. Look at Microsoft now. They have this open culture internally as well as externally. Visual Studio Code is open source, and Microsoft became one of the top open source contributors, as well as a big advocate for inner source.

[00:23:55] A few tips here. If you're leading a team, or you have some influence on the leadership team's decisions, try to be an advocate and push for this type of change, because having executive leadership vision and support will make your whole organization's inner source journey a bit easier. If you're maintaining a project, try to celebrate any contribution someone from outside your team or department makes. That satisfaction can encourage others as well.

[00:24:26] If you're working on a project, give your team a few suggestions or changes to make. Maybe start by changing the repository visibility to internal when possible. You might think, "Oh no, my code needs a lot of work before I share it." But guess what: if it's working, that's fine. You don't need to tidy up the code and make it perfect before sharing. That's not really the point here. Documentation: improve your project documentation. Don't say "my code is my documentation." That might make sense to you right now, but it won't make sense to someone else who's trying to pick up your project in a year or two, or maybe more.

[00:25:04] You might think, why would I bother with this whole inner source thing if I'm going to get one, two or maybe three contributors from outside my team? But remember when we spoke about productivity improvement: when someone just consumes your code in their project and it makes their life easier, that's how you're indirectly contributing to productivity improvement across your whole organization. The situation might be reversed one day, and you might be the one using another team's code and benefiting from it.

[00:25:39] Some of you might be working in financial industries or government, and you might think it's going to be very challenging for you to have that open culture. But if you dig a bit more, you might find some libraries, some algorithms, or some small projects that aren't considered top secret and can be shared internally. I have seen it done very successfully in some banks globally, as well as in our APAC region.

[00:26:06] In conclusion, everyone wants to change, not the world, but maybe the organization where they work. Together with your colleagues, with your co-workers from all over the organization, you can work together to get there faster and make a better impact. I'd like to share some resources with you. I'll be sharing the slides at the end as well, so you can get access to all of these links. And at the end I just want to say thank you for watching and thank you for your time.