Going straight from closed-source to Open Source is not always possible, and it can also be a hard transition for the maintaining team as the required processes are very different.

To address that, somebody floated the idea that one could be requiring InnerSource before Open Source, sort of like an incubation phase inside of the company to see if a project has the potential to become Open Source. The InnerSource Incubation Phase would also allow the maintainers of the project to practice all the things required when a project starts to receive contributions from outside of the core team, including improving documentation and review processes accordingly. For the time being let's call this InnerSource Incubation.

There might be another branch of this idea, where Open Source isn't possible for some reason e.g. any intellectual property that the company doesn't feel comfortable sharing in the open. In that case InnerSource could be an attractive alternative to Open Source because through InnerSource the maintainers still get some of the benefits of exposing their project to a wider audience. For the time being let's call this InnerSource as next best alternative.

Focusing on the InnerSource Incubation for now, some specific ideas that would make such a pattern really interesting and valuable for readers:

• how is the InnerSource Incubation phase is explained to the maintainers of a given project?
• interview the maintainers of a project that have done through the InnerSource Incubation and have eventually released their project as Open Source. Ask them what the experience was like especially what of the incubation phase was most useful for them to prepare for Open Source
• how long should the incubation phase be?
• who would facilitate the incubation phase? Is that drive by the OSPO of the company? (assuming there is one)