[Pattern Draft] Require InnerSource before Open Source

[spier]

Closes #285

I have created a first draft around this idea, even though I don't have an organization at hand that can confirm that they are using this practice. Therefore this is a draft/initial pattern.

However I hope that by sharing a draft it becomes easier to get other orgs to contribute their experience to this idea, as they don't have to start writing this pattern from scratch.

Some things that could still be done to improve the content of this pattern:

• Find organizations that have written/spoken publicly about similar concepts (likely not using the exact words used in this pattern) / contacting people at larger OSPOs might be a good way to go way to go about this
• Research if some of open source foundations have specific suggestions for organizations before those publicly launch a project as open source
• Solution section / could be extended with some specific examples like "how long a project should run as InnerSource before it can go open source" etc
• double check spelling of "open source" vs "open-source" etc
• link to other patterns e.g. in the Solution section

Appendix

From https://opensource.guide/starting-a-project:

If you’re a company or organization:

• You've talked to your legal department
  • Relation to this pattern: for larger orgs with multiple legal entities, even the process of publishing the project as InnerSource might help to work out the legal challenges
• You have a marketing plan for announcing and promoting the project
  • Relation to this pattern: marketing and promotion activities also have to be done by InnerSource projects, to gain adoption internally
• Someone is committed to managing community interactions (responding to issues, reviewing and merging pull requests)
  • Relation to this pattern: this is the area that the pattern currently focuses on the most
• At least two people have administrative access to the project
  • Relation to this pattern: should be a given :)

From https://dev.to/captainsafia/so-you-wanna-open-source-a-project-eh-5779

• empathy training for employees
• management structures for open source (and InnerSource!!!)

From https://www.eclipse.org/projects/handbook/#incubation

• proven number of adopters
  • Relation to this pattern: this could be one of the exit criteria to go from InnerSource to open source (i.e. once you have found X other teams adopting and/or contributing to your service, you can release your project as open source

From https://www.linuxfoundation.org/resources/open-source-guides/starting-an-open-source-project:

Questions to Ask Before Starting an Open Source Project

1. Can we financially sponsor the project? Do we have an internal executive champion?
   • Relation to this pattern: during the InnerSource phase of the project, finding an executive champion might be easier, given that you can prove some internal adoption and broader project value.
2. Is it possible to join efforts with an existing open source project?
3. Can we launch and maintain the project using the OSS model?
4. What constitutes success? How do we measure it?
5. Will the project be able to attract outside enterprise participation (from the start)?
6. Is there enough external interest to form and grow a developer community?

From https://ben.balter.com/2015/03/08/open-source-best-practices-internal-collaboration/:

I love this quote:

To think you can breed code in captivity behind a firewall, using closed, hostile, or waterfall methodologies, and that once that code leaves the firewall, it will grow wings, is a fundamental misunderstanding of what it means to participate in the open source community.

So if you are managing to run your project as InnerSource at least for some time, you are forcing yourself to develop more open processes around your project. This will be a good preparation for releasing it as open source later.

[fer-correa]

LGTM 👍

What is presented here reflects very well what we have as generic practices.
We use badges to identify the stages of the project in this innersource journey (ready, Active, Attractive, champion) to further engage teams in this evolutionary process.

[fer-correa]

Thinking in feedback loops: a project can regress in its status, for example, cases of outdated documentation generate a "no longer innersource ready" alert, issue response time (helps to evaluate the quality of maintenance), etc.

[spier]

Very true.

We should describe somewhere that not all of these projects will always be turned into open source. It should be rather obvious but maybe we should spell it out :)

This incubation phase as an InnerSource project is a quality gate, and not all projects can pass that gate. It is meant to achieve multiple things:

• sufficiently harden the async collaboration nature of the project, so that it is ready for open source
• forces the project to prove its worth internally (I wonder if there are cases of project that would be great as as open source but still they would not find a 2nd internal adopter)
• (I am just realizing that I start so type similar things again that we already have in the "Resulting Context" :))

[fer-correa]

Very true.

We should describe somewhere that not all of these projects will always be turned into open source. It should be rather obvious but maybe we should spell it out :)

I agree.
It may seem obvious or repetitive, but I see that every project that aims to be open source must go through the innersource phase. This phase will bring maturity to the project and those responsible. At the same time, not every innersource project will be able to be published as open source (maybe by strategy, by completely organizationally-driven use, etc.)

This incubation phase as an InnerSource project is a quality gate, and not all projects can pass that gate. It is meant to achieve multiple things:

• sufficiently harden the async collaboration nature of the project, so that it is ready for open source
• forces the project to prove its worth internally (I wonder if there are cases of project that would be great as as open source but still they would not find a 2nd internal adopter)

Here, for this case, I really don't have any examples to share. Maybe, if we consider the size of the organization, there may be cases where a project is great and could be used by several other companies and people, but as an innersource it may attract people interested in contributing because the technology or proposal is interesting but still not be cases of reuse by the organization's teams... does what I said make sense?

• (I am just realizing that I start so type similar things again that we already have in the "Resulting Context" :))

[spier]

We use badges to identify the stages of the project in this innersource journey (ready, Active, Attractive, champion) to further engage teams in this evolutionary process.

@fer-correa I assume these stages are used, no matter if a project wants to become open source eventually or not, right?

Could you define these 4 stages in a bit more detail?

[spier]

Thank you @fer-correa for the insights from your org. I left some replies. Let's see how we can work your feedback into the pattern.

Btw feel free to use inline suggestions if you want to make text changes to the pattern.

Of course you can also fork and send pull requests towards this branch :)

[spier]

Very true.

We should describe somewhere that not all of these projects will always be turned into open source. It should be rather obvious but maybe we should spell it out :)

This incubation phase as an InnerSource project is a quality gate, and not all projects can pass that gate. It is meant to achieve multiple things:

• sufficiently harden the async collaboration nature of the project, so that it is ready for open source
• forces the project to prove its worth internally (I wonder if there are cases of project that would be great as as open source but still they would not find a 2nd internal adopter)
• (I am just realizing that I start so type similar things again that we already have in the "Resulting Context" :))

[spier]

Would you like to add your org as a known instance here?

[spier]

@fer-correa would you like to add your org here as a known instance? If you don't feel comfortable doing that yet, or have to get some sort of approval, I totally understand.

[spier]

Hi @fer-correa.

Thank your for your feedback on this PR so far!

Do you have time to review the inline comments as well as the comments above?
I am looking to merge this PR as an initial pattern fairly shortly, as we are starting to hear about other organizations that are using similar approaches. It tends to be easier to add those orgs to a pattern, when we can point to a pattern in our repo (rather than to a pattern that only lives in a PR :))

Btw I added you as a co-author of this pattern. Hope that is fine for you? See b92c0ff

[fer-correa]

Sorry for the absence.
Let's get this PR back on track... thanks for the reminder, @spier .