Originally coined by Tim O’Reilly, inner source is an engineering principle that aims to bring open source methods inside the four walls of an organization to build proprietary software. The openness in question extends across teams within an organization, rather than spanning multiple contributors from different organizations.This brings with it a set of common techniques and tools used in open source communities that allow large groups of contributors to work together on code that isn’t necessarily their primary responsibility. This typically includes the use of shared code repositories, pull requests, comments, and extensive documentation.It is a methodology that is starting to prove increasingly popular with more traditional enterprises looking to modernize their software development practices and start to view their code as collaborative, reusable assets, rather than as intellectual property that must be kept under lock and key by the team responsible for it. The inner source approach also removes upstream blockers by empowering developers to make changes themselves via pull requests, in a safe and transparent way.The adoption of inner source will require a significant culture shift for certain organizations, but it can help boost the quality, reliability, and security of your code, while also fostering greater collaboration and developer velocity by breaking down long-standing silos—something that took on even greater relevance during the pandemic.“If there is one thing inner source has proven, it is that massive peer-based collaboration across asynchronous teams can be just as effective as tightly controlled teams in the same room and time zone,” Danese Cooper, founder of the InnerSource Commons Foundation, told InfoWorld. Those same attributes were key to navigating work during the COVID-19 pandemic, helping to prove the effectiveness and encourage the adoption of the inner source approach.InfoWorld spoke to three companies adopting inner source methods to see why inner source suits them and what it has helped their developers achieve. Bloomberg: Empowering engineers to be the change they want to seeOne industry where inner source has taken root is financial services, where organizational silos and a conservative, often secretive approach to not sharing code has long been the norm.“Inner source for us at more traditional organizations is a change from the old world of swimming in your lane,” said Gil Yehuda, head of open source at US Bank, during the Open Source Strategy Forum in London in October 2021. “The notion of protecting code by not sharing it is a thin veneer, because of the deep dependencies we all rely on. It is healthier to view them as a shared, common pool of assets we can all benefit from.” On the same panel that day was Arthur Maltson, a distinguished engineer at Capital One, who said “there is lots of code sharing and cross-line of business contributions to platforms today at Capital One. As engineers mature, code becomes a means to an end to solve a business problem and that is best achieved by being inner source and being more open. Problems are solved better with more people. We need to get past having an excessive ownership culture amongst engineers.”At Bloomberg, inner source has slowly become the norm over the past 10 years, spreading out from its roots in the internal developer tools team to now being an accepted way of working for cross-asset trading and other key applications.“Now more than ever before, engineers across the company are empowered to be the change they want to see in another team’s code base, whether it is a simple bug fix that makes a client happy, or an important feature that improves productivity across a large group of engineers,” said Joe Patrao, team lead at Bloomberg, during a presentation earlier this year.Today, every engineer at Bloomberg uses GitHub Enterprise to view and collaborate on code with colleagues, including clear contribution and testing guidelines. “We use pull requests and code reviews to land changes, and the standard of what one expects from a [pull request] does vary from team to team,” Becky Plummer, software engineering team leader at Bloomberg, told InfoWorld. The threshold for making a pull request for an internal tool may be lower than for a highly regulated trading application, for example. Before these inner source methods were brought into Bloomberg, an engineer would have had to contact the relevant product manager to request a feature or integration, slowing down developer velocity and hindering cross-team collaboration. “Over the years, we have learned that it is a phenomenal learning experience and also provides value and accelerates product delivery,” Plummer said.BBC: Reusing code to speed up feature deliveryThe British Broadcasting Corporation, UK’s national broadcaster, has organically developed an inner source culture over the past four years. It has brought internal teams closer together, enabled better collaboration across departments, and driven more efficient software development cycles.In the TV applications team specifically, which focuses on the hugely popular iPlayer and Sounds applications, open source was already well understood, because that team had already open-sourced its own TV Application Layer in 2012. But the practice was less common across the rest of the organization.“We were already big consumers of open source, and when we open-sourced our own software, like the TV Application Layer, that really drove an inner source culture,” Tom Sadler, software engineering team lead for the BBC’s iPlayer and Sounds applications, told InfoWorld. “It was born out of necessity across 10 teams working on TV app development, where being able to collaborate across those teams was really important.” For example, the launch of Sounds on TV—a radio application for smart TVs launched by the BBC in March 2020—was able to get to market quicker than anticipated thanks to the inner source culture across those teams by reusing code from the previously launched iPlayer TV application, rather than starting from scratch.By using consistent pull-request and continuous delivery processes across teams, that inner source approach to software development started to spread. “Rather than needing a team to do something for us, we shifted to working with them,” Sadler said.In terms of how changes are processed and approved at the BBC, it comes down to internal judgment around what constitutes a major or minor change. For minor changes, there is an element of organizational trust that kicks in. For more significant changes, the BBC follows a request-for-change process similar to large open source projects like the Rust programming language, where anyone directly affected by that change has the opportunity to comment and suggest alternatives before the change is merged.This culture really paid dividends during the pandemic, where asynchronous collaboration was vital when developer teams went remote. “Having a pull-request mentality, conversations on Slack and Teams, and installing mechanisms for making cross-team decisions definitely helped us during the pandemic,” Sadler said.Asos: There should be no surprises in a PROnline clothing retailer Asos had the advantage of very little legacy when it came to establishing inner source across its 70 or so engineering teams four years ago. “Those teams are devops, agile, owning their own applications with a good level of autonomy, so we saw an opportunity to accelerate cross-team delivery,” Dave Green, director of architecture and engineering at Asos, told InfoWorld.By accelerating that inner source mentality across teams, Asos was able to break down some organizational silos, encourage code reuse, and get more eyes on code to drive up quality. “We want to bring walls down so everyone can see everyone else. Transparency and good communication allow us to build communities within Asos,” said Asos’s principal engineer, Tony Gorman.“The idea is to make the code better and enable more capabilities and respect that code is owned by someone—everyone is precious about code in some ways—so doing things clearly and transparently is key,” he said.That doesn’t mean it was all smooth sailing, however. “It’s a journey. You write code differently when you know others will see it and contribute than when it is internal-only. Documentation and automation are key,” Green said.Not too many mistakes were made in those early days, according to Green and Gorman, but there was one case where a frustrated engineer decided to push a new feature without following the proper process before going away on holiday. “That led to a robust conversation,” Gorman said.This journey led to something of a mantra emerging across Asos: “There should be no surprises around a PR [pull request].” By using GitHub and Microsoft Azure Repos, alongside collaboration tools like Slack and Microsoft Teams, Asos engineers can safely work in an inner source way, where cross-team collaboration has become the norm.Now Asos is seeing internal projects develop in ways that might be worth open-sourcing back out into the community. “There is a desire to give back,” Gorman said.Where to start with inner sourceMany of the engineers InfoWorld spoke to pointed to PayPal as the gold standard for getting started with inner source.Other helpful resources for getting started with inner source include the e-books Getting started with InnerSource and Adopting InnerSource.For an active community around inner source, look no further than the InnerSource Commons, complete with blogs, a wiki, a Git repository, a learning path video series on YouTube, user stories, and tried and tested patterns.
Copyright © 2021 IDG Communications, Inc.
Source link