Inner Source development is a software development process that helps developers create code that is more maintainable and reliable. It’s a popular approach for large, complex projects, and it can be used on both desktop and web applications. If you’re considering using Inner Source development, there are a few things to consider. First, it’s important to understand the benefits of the process. Second, you’ll need to decide whether your project is suitable for this approach. Finally, you’ll need to set up and use the necessary tools. If you’re ready to take your software development process to the next level, give Inner Source development a try. ..
Open source workflows facilitate easy collaboration and rapid iteration. Publicly accessible issues and merge requests on platforms like GitHub let anyone contribute to a project. Bugs are discovered and patched quickly, safely, and transparently in an environment that fosters regular discussion between maintainers and users.
This model can contrast starkly with how software’s developed inside large organizations. In these environments, tools are developed in an ad-hoc fashion by individual teams. People work in silos, contributing to their individual areas, oblivious to overlapping work that’s going on elsewhere.
Introducing Inner Source
The inner source movement applies lessons learned from open source development to an organization’s internal projects. It advocates making all code visible to everyone, creating a more open culture where teams can find existing projects that might also be useful to their work, then contribute their own improvements.
In many organizations, new source repositories will be locked down to just the individuals that need to work on them. Adopting an inner source model means making everything visible by default. This encourages team members to explore the organization’s entire corpus of code and provide input to discussions, even if the project’s not strictly within their subject area.
Inner source isn’t just about code either. It can be extended to include broader assets and documentation relevant to the business, its operations, and its software. The objective is to empower individuals to self-select tasks and contribute their experience where they feel it would benefit the organization, even if they’re hired into a specific focus area.
Inner Source Benefits
Proponents of “inner source” architectures note several significant benefits of the approach, including reduced waste, accelerated launch times, less tension between teams, and improved code quality. These combine to enhance the organization’s productivity and workplace culture.
Reduced waste, enhanced reuse – Large organizations can end up duplicating similar code across multiple projects owned by different teams. If teams aren’t talking to each other, the fact you’ve now got three similar caching libraries could go unnoticed. Publishing all code internally will alert others to the presence of usual tools, then encourage shared iteration on a single codebase. The wheel stops getting reinvented, keeping everyone on task and accelerating the launch timeframe. Improved code quality – Code written in the open is more exposed so bugs are likely to appear earlier in the development process. If a shared library is adopted by a new team, issues could come to light that were unnoticed before. Implementing fixes will benefit all the projects using the library. Less tension between teams – While moving to an open model might seem uncomfortable at first, inner source development is meant to break down barriers and enhance collaboration. Closed development can create uneasy situations when you find a neighboring team’s built a better version of a library you’ve been using. In an open model, this is resolved by iterating together on a shared codebase that includes the capabilities needed across the whole group.
Inner source flattens the organizational structure, giving all developers the same view into ongoing work. Accepting contributions from outside the team that “owns” a project provides access to fresh eyes and an expanded pool of solutions.
Implementing an Inner Source Workflow
At its simplest, inner source is implemented by heading to your version control platform and changing the visibility of projects from Private to Internal. In practice, you’re going to need a more considered plan than this if you’re to successfully introduce the inner source model to an existing team environment.
There are two fundamental aspects in any transition: communication and tools. The former refers to educating team members about what’s happening and how they’ll be able to contribute to opened projects. “Setting and forgetting” access levels will be ineffective as people will be unaware of their new abilities and when they can be used.
The second aspect, tools, involves selecting appropriate software utilities to manage the open workflow. A functioning software team will probably already be using a form of version control, such as GitOps, to manage their code. However, precise usage patterns could vary considerably throughout the organization.
Inner source calls on a unified development model that’ll work consistently across all projects. This means using the capabilities of Git and your hosting platform, such as GitHub or GitLab, to their fullest effect.
Contributors should be able to submit changes in a pull request which maintainers then review and merge. Pull requests should be supplemented by a passing test suite which runs in a CI pipeline. This gives the maintaining team confidence that the change is effective and ensures all code meets the same standards. Making the codebase self-verifying through automated tests and checks helps remove friction from the experience.
You should also consider how supporting assets such as documentation and issue lists are stored and exposed. Create an open team wiki for API docs and architecture references; ensure all bugs and feature requests are tracked in a central location. This will let people from across the organization find the information they need. It also empowers individuals to provide enhancements to arbitrary projects in quieter periods – anyone can find bug reports and start addressing them, leading to improvements in all downstream repositories.
Drawbacks to Consider
Inner source is already a reality at many organizations. The potential benefits are alluring in situations where increased efficiency and throughput are desired. As with any approach to work, it’s not necessarily suitable for every environment though.
One of the most frequent concerns about inner source is its impact on security and information disclosure. The similarities between inner source and the wider open source ecosystem only extend so far: the code in an open library or framework contains nothing of sensitivity, whereas you may deal with closely guarded proprietary systems in your role at work.
It’s natural that some projects will always need to be locked down, accessible only to stakeholders and the directly responsible implementation team. However, possessing some high-stakes projects with sensitive source, where it’s not safe to make them visible across the whole org, shouldn’t spell the end of an inner source initiative.
It’s still worthwhile opening up projects that can be safely exposed. You could also abstract the non-sensitive parts of private projects into new shared libraries that are publicly accessible. This brings the benefits of inner source closer to your sensitive assets without actually revealing them.
Another inner source challenge is communicating expectations back to developers. Devs may be wary of exploring open projects, especially if inner source is introduced to a historically closed organization. This can be addressed in a variety of ways, such as allocating time for developers to inspect code written by other teams.
It can also be helpful to start off small, only exposing core libraries that will be useful to many different teams across the organization. A good choice can be a well-known but private component which has a reputation for being unreliable or outdated – think “reported bug with the ApiClient again.” Opening up that component enables developers to contribute their own fixes as they need them, improving productivity and promoting organic growth of the inner source mentality.
If you do try this technique, be careful to warn the original project authors first – even if it leads to greater efficiency all-round, some individuals could treat others contributing to code that was formerly “theirs” as an affront. Communicate why inner source is being introduced to the organization, as well as the specific reasons for opening individual projects.
Conclusion
Inner source refers to taking development methods from the open source community and applying them to internal projects and processes. It facilitates unimpeded access to useful code and documentation while promoting collaboration and communication.
Implemented correctly, inner source can be a differentiating point for an organization that reduces redundancy, increases throughput, and fosters a more equitable development culture. Choosing to leave projects open by default lets the original authors tap into the human talent of the entire organization. In the same way as leading open source frameworks and libraries harvest the collective abilities of the community, so can inner source create internal tools which go beyond what any single team could achieve.
Inner source can be tricky to get right. It can lead to pushback from code owners and wariness on the part of developers. When introducing any form of inner source development, keep people on the same page by clearly documenting expectations and working procedures. Everyone needs to feel comfortable in contributing for the full benefits of inner source to become apparent.
