InnerSource is the application of Open Source collaboration best practices inside of the confines of corporations. This makes understanding two aspects of Open Source easier for teams through parallels with InnerSource:
Much like in InnerSource, Open Source projects have different governance levels. Not all Open Source projects are created equal: While some groups only publish the source code, expecting no interaction, others want downstream users to become active and submit patches. Other projects have processes set up to allow for sharing impact on the Open Source project. Understanding these governance levels means that deciding which open source project to use in house will take Open Source governance into consideration as well. A downstream user of an InnerSource project will have learned to correctly evaluate the balance between moving fast but being unable to influence a project vs. moving at a slower pace but being able to influence a project together.
Working in InnerSource projects helps teams practice what it means to share the cost and effort to build platforms together. Sharing the work across teams helps innovate faster overall: Product teams with different focus areas can join forces to develop a needed base platform faster and share the resulting maintenance load.
The same dynamic drives several Open Source projects as well. Understanding it means that participation in these projects is natural for any team that has experience with InnerSource. Knowing that dynamic from practical experience also makes it easier for teams to recognise which open source projects are being developed according to these principles. Typically this understanding subsequently also has an impact on which Open Source projects teams decide to use internally.
Platform features that many teams need can then be created by collaborating instead of re-implementing them locally over and over. That makes it easier to understand the concept of how sharing effort can help to make the pie bigger for everyone and how it can help drive industry standards if done in an open source way instead of only internally.
In terms of mechanics both practices are very similar. The major difference is the visibility of projects: For InnerSource that is limited to the corporation, for Open Source they are public.
What sounds like a tiny difference on paper is a huge difference in practice. Going Open Source means that each and every message is publicly visible and potentially archived forever. This implication can be very uncomfortable in particular for employees not used to that way of working. In addition all actions being public means they are also available for public scrutiny - no longer can every move be vetted by corporate communication experts. Similarly produced artifacts are available for public scrutiny with regard to license compliance, security and the like - e.g. for competitors, for potential future new hires, for customers.
On the other hand it also opens the door to collaboration with others outside of the walls of one corporation - taken to the extreme that can result in co-opetition where competitors join forces to build a common technical platform, innovating and competing against one another on top of that.
Going open source also reduces the tax implications of collaborating across the boundaries of legal entities. While transfer prizing as a hot topic for many InnerSource effort it is irrelevant for any Open Source project.
While "what about publishing projects as Open Source" often is the first thought when talking about becoming active in the Open Source space. When experienced with InnerSource it becomes clear that publishing entire projects is only one way of being active in the open source space.
Instead it is much more natural to adopt an enlightened self interest point of view: * Where teams use certain Open Source dependencies in vital parts of their components it is important to ensure being involved upstream - even if the only goal is to understand the future roadmap of the project. * Where teams have a need for changes in open source projects they depend on, experience with InnerSource makes the advantages of participating upstream obvious: Clearly it is not only about a "sharing is caring" mindset - but it does have clear economic benefits where contributing teams have a highly reduced maintenance overhead if their changes are integrated upstream.
Taking another step back even the decision of which Open Source project to adopt and use internally will be influenced by the InnerSource experience of a team: * InnerSource trains teams to understand what to look out for in terms of ways of collaborating and communicating - from personal experience they will understand why it’s important for project to have clear, archived, searchable communication channels. They will also understand why it’s important that every major project decision is taken on these communication channels. * Understanding the different governance levels in InnerSource teams are well prepared to understand the implications of Open Source projects operating according to different levels of openness.