Pattern idea: (Project) Adopters pattern

[dellagustin-sap]

Suggested by @spier as a reaction to SAP/project-portal-for-innersource#38 .
Issue has yet to be defined, but in summary, the idea of recording users/adopters of an InnerSource project should become a pattern.

References

• Related threads on ISC Slack
  • Call to action to register adopters on the SAP/project-portal-for-innersource - https://innersourcecommons.slack.com/archives/C04PXKRN4/p1660307419013239
  • Discussion where this pattern was suggested by @spier : https://innersourcecommons.slack.com/archives/C2EFRTS6A/p1660307566174429
• Adopters at the SAP/project-portal-for-innersource
  • ADOPTERS.md - used a permalink to avoid broken version, so be sure to look for newer versions
  • Reference PR - Added ADOPTERS.md SAP/project-portal-for-innersource#38

Related issues

• Call-out on website to collect Known Instances #418

[dellagustin-sap]

I have the intention to contribute with this one.

[spier]

Pretty random thoughts below. Have to get back to this later.

Open source projects sometimes share a list of adopters/users of their project.
Likely as a way for them to do marketing.
The more well known the adopter is, the better for the project so that they can showcase that their project has been vetted.

So one could argue that this is a pattern in open source already.

Examples of this in open source:

• https://github.com/lycheeverse/lychee#users
• https://github.com/openfaas/faas/blob/master/ADOPTERS.md

Applying the pattern to InnerSource

Now when applying the pattern to InnerSource, what are they key differences?

Also what specific problem does the approach solve?

Is it that it helps other users to hear it straight from the horse's mouth, i.e. from other users that have already adopted the given project? ¹

What alternatives are InnerSource projects competing with?

• open source projects doing something similar - i.e they have to be sure about "why is it better to use our InnerSource project than those open source projects"
• teams rolling their own (resulting in some level of code duplication)
• ...

Footnotes

1. A bit like the short version of the case studies, that many product companies share on their website/blog. ↩