[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]

In our case, the project may be made available to other teams for contributions, but step 2 is so important that we only consider the project to be truly ready once this step has been reviewed and approved (innersource ready status).

[spier]

Who does the review of this step?

Also what is the consequence of becoming "innersource ready"? e.g. is the project only published in your InnerSource Portal once that stage has been reached?

[fer-correa]

I really liked the way these steps are listed. It reflects a lot of what we do.

We measure what we call the activity and attractiveness of the project.

We also measure the popularity of use (the focus of reuse in innersource) of the project by others, which shows us how valuable it is to the organization.

[spier]

How do you define activity and attractiveness?

For activity we have this pattern that sounds related? repository-activity-score.md

I like popularity. Mathematically this sounds like a count of teams that have adopted the given project? or how do you measure it?

[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" :))

[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]

Who does the review of this step?

Also what is the consequence of becoming "innersource ready"? e.g. is the project only published in your InnerSource Portal once that stage has been reached?

[spier]

How do you define activity and attractiveness?

For activity we have this pattern that sounds related? repository-activity-score.md

I like popularity. Mathematically this sounds like a count of teams that have adopted the given project? or how do you measure it?

[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?