Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
Consider the typical software development practices in an organization. Projects are commonly closed, and causes friction across engineering teams. But open source communities work asynchronously, openly, remotely and at global-scale. What if our internal teams could reuse those same practices?
Modern software engineering practices are essential to deliver value to your users. After all, isn’t that the promise of DevOps? A combination of people, process, and technology to accelerate delivery of value to end users?
Value could mean many things. It could mean running a reliable service where your users experience limited downtime. It could mean accepting and prioritizing users’ feedback, focusing on features that they want to see. Or it could mean prioritizing quality over new features, enhancing your testing, compliance, monitoring, and governance structure for building and releasing new iterations of your products and services.
It’s important to remember that technology (or tooling) is only one part of the problem. People and processes can have a profound impact on the uptime of the services we run, the flexibility to ship, and the ability to innovate.
Consider the typical software development practices in an organization. Projects are commonly closed, and access has to be requested and approved with an appropriate justification. This can cause friction across engineering teams in your business, leading to silos and duplication of effort across teams.
Now think about the way that many open source communities work. They work asynchronously, openly, remotely at global-scale. Decisions are made out in the open and external contributions are welcomed.
You may have heard of Conway’s Law, the idea that software is shipped based on the organizational structure. Organizational structures are great for managing businesses and helping steer disparate business units towards a common goal. But there may be limitations. If two teams are unable to collaborate, is there some missed opportunity to innovate? If you’re shipping software based upon the organizational structure, does it bring in the mentality of “That’s not my problem. That is owned by team B.”?
In this blog, we will explore the common challenges that a business may face in structuring their teams. After that, we’ll discuss innersource, and how GitHub can help in building an open community within your organization.
Let’s bring this back to a couple of patterns that I’ve observed in my time working with many software engineering teams.
If teams are closed by default, then silos naturally appear. These silos cause friction between engineering teams and result in several teams solving the same challenges. In other words, reinventing the wheel.
To encourage re-use and optimization, organizations may adopt a center of excellence to act as the custodians of the centralized and sharable resources. While this model sounds like a step in the right direction, operational challenges can cause friction.
Consider the diagram below: four application teams, with a center of excellence. To simplify, let’s also assume that all teams are using the same programming language.
The application teams are typically a ‘customer’ to the CoE. In other words, the CoE has a backlog of work which has been influenced and prioritized based on requests from application teams (illustrated by the message icons in the below image).
However, there’s a challenge here — application teams have different priorities.
What if application team A has a critical requirement for their release? Are their needs more important than teams B, C, or D? Should the center of excellence prioritize their backlog to accommodate? If so, which team’s work gets deprioritized as a result?
At this point, we see that organizational politics could unfold. The application teams are likely still working in silo, but instead relying upon a centralized team as a bottleneck and source of friction.
Now, let’s discuss communities of practice, which could be considered as an evolution of the center of excellence model.
Rather than a central team serving the application teams, subject matter experts across the application teams come together as a virtual team, collaborating on the common goal for that community and the wider organization. This approach nicely aligns with the concept of innersource. A group of individuals who are not necessarily in the same team or business area, but collaborate to solve a common goal.
Some challenges still remain. Who makes the ultimate decision on a group’s roadmap? What if there is a breaking change? Who is responsible for owning and maintaining the work from the community of practice?
While this blog isn’t intended to help you solve those organizational challenges, it highlights the complexity of organizational structure, and how innocuous decisions can impact your organization.
So, the fundamental question is this: are open source practices limited only to open source teams? Absolutely not! You can adopt these practices internally, using innersource principles. This is the concept of adopting open source practices for proprietary software engineering within your organization.
In fact, the InnerSource Commons is a community of practitioners who have come together to document and share these practices, so that organizations can embark on this journey as well. There are several patterns that you can learn from, including:
Rather than having siloed teams which focus on their core day-to-day work, you can enable a cultural shift. Instead, you can enable and empower your engineering teams to collaborate across organizational boundaries, fostering and facilitating innovation.
With modern engineering practices like innersource, your teams can also work like open source communities. They can work asynchronously, openly, remotely at global-scale, making decisions out in the open, and welcoming contributions from teams across your organization.
And the best part? The DevOps practices that you have been building into your development life cycle are all completely relevant. If anything, they’re more important than ever.
As the home of developers and many open source communities, we know a thing or two about open source communities. The platform is continuously evolving to cater for the needs of the global developer community, including those building proprietary software in businesses.
Here are a couple of quick tips to get you started:
Internal repositories are available if you have adopted GitHub Enterprise. They allow you to provide access to any users in your enterprise Account. This makes innersourcing much easier, by providing visibility across your entire organization.
Of course, it’s not always going to be possible to set a new project’s visibility to internal. In some cases, you may have a project which is sensitive (for example, if you are bringing a new product to market, or some sensitive IP has been incorporated), or restricted due to external regulatory requirements. But, if you can ‘flip the problem’ so that repositories are internally visible by default, then that starts reducing the ‘siloed teams’ problem, and provides visibility across the business.
When writing code, you typically want to follow a consistent process to bring changes to your codebase. Ideally, there would be a set of quality gates that must be passed before the changes can be brought into production. This is where branch protection rules come in. They allow you to enforce standards, so that quality can be maintained.
Protection rules can be combined with status checks to ensure that your code is meeting a set of conditions.
These checks could include tasks like test execution, build verification or validating that no new security vulnerabilities have been brought into the project. Required status checks can be mandated on a repository by using branch protection rules, encouraging practices that lead to higher quality code being pushed to production.
You may have members of your team that specialize in certain areas of the codebase, and are best placed to review any proposed changes. If this is the case, then you may want to investigate CODEOWNERS files.
The CODEOWNERS file allows you to specify individual users or teams as required reviewers whenever a change is made to a set of protected files or folders.
For some organizations and engineering leaders, the prospect of innersource may seem daunting. However, there are several considerations to help mitigate risk while ensuring your teams can continue innovating and being successful.
With GitHub Advanced Security, you can configure several features, such as Dependabot and secret scanning at the repository, organization, or enterprise level. This means that you can encourage teams to follow and resolve security alerts quickly, by making this an open standard across your organization.
Find out more details about managing GitHub Advanced Security features for your enterprise.
If you’ve reached this stage of the post, congratulations! You’re likely interested in exploring innersource further, and how it could help bring a culture of innovation in your business. Check out our innersource landing page for further tips and tricks on how you can get started.
Don’t want to start the journey alone? That’s okay! Our expert services team may be able to help you, too!
