What is a good candidate for an InnerSource project?

[dellagustin-sap]

In principle every project is a candidate. For this topic, I like to refer to this blog post from Arno Mihm: InnerSource - a better way to develop?

Ideally you want to look at all your company internal code as InnerSource candidates and all the code you can share with the world as open source candidates. Why all of it? You essentially want to maximize the potential for collaboration in both worlds. By including all of the code (obviously except where legal or business reasons speak against it) you also make it easier for developers as you introduce a single concept: Sharing code / documentation where possible.

Now for good candidates, I think there are different aspects (or dimensions):

• Low hanging fruits (Complexity)
  • Documents as code - documents maintained as code (e.g. Markdown files) are low handing fruits
  • Libraries and internal tools (reusable artifacts) - when already well maintained (dev documentation in place, easy to onboard, quality gates in place)
• Lighthouses (Notoriety) - can lead by example and help spread the word
  • Projects with high visibility
  • Projects with a lot of users - e.g. internal tools used by many employees, specially ones with dev skills - a lot of potential contributors

[claredillon]

I created the following list of InnerSource project types as a summary of what we have heard in our community calls:

• Any project that is being worked on by a team that is geographically dispersed, perhaps over different timezones.
• Shared Services / Platform projects have reported that InnerSource helps smooth the transition to shared services - giving team who are dependent on shared services autonomy to make changes they need and a sense of control/involvement in the direction of services they are dependent on. IBM tell the story of how Watson NLP became a AI service used across IBM once they enabled InnerSource.
• A particular case of shared services are DevOps projects - an example here is Capital One. Their DevOps initiative uses InnerSource to enable all the teams they work with to make their own required changes to the DevOps platform. Anecdotally, we have heard a lot of orgs talk about how DevOps projects were the reason they started InnerSource.
• A project you intend to open source, but first you want to prove the team have the competencies required to build community / handle contributions from folks external to the team. This is the process used at Comcast.
• Community projects - an example here is the shared bus timetable at PayPal. Sometimes having groups of developers work on a community project together, not related to core development priorities, can be a good first InnerSource experience.
• Projects that need innovation at the edge - where you have a distributed team and you want to make sure that there is quick turnaround/response need for, say, customer-facing team members. Microsoft's case study of creating consulting resources is a good example of this.
• Club goods - for projects where two organizations want to collaborate in a consistent way on a piece of code over time, but not make the full code base open source. The term "Club goods" was shared with me to differentiate from "public goods" as is referenced in the UN's Digital Public Goods.

[spier]

This pattern draft by Tapajit Dey and Brian Fitzgerald may also be helpful - both researchers I believe: https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/good-first-project.md