Does the innersource-scanner implement an InnerSource Pattern?

[spier]

Hi there!

Over in the InnerSource Patterns working group (part of the InnerSource Commons) we were wondering what experiences you have made with your innersource-scanner so far? Is it achieving the goals that you have set for your project (e.g. the ones described under Motivation)? What feedback did you receive internally? What further challenges did you discover while applying the scanner in your org? Do you plan to modify the scanner to address some of those challenges?

As our goal is to collect InnerSource Patterns, we would naturally like to find out if the innersource-scanner is tooling that can support any of our existing patterns (e.g. the possible the Standard Base Documentation pattern) or if it represents an entirely new pattern?

We would love to learn more about your experience, so thank you in advance for anything that you can share.

As an aside:
We filed an issue to track this topic at InnerSourceCommons/InnerSourcePatterns#393, however we think it might be best to have this conversation in this Discussion thread here, as it is closer to your community.

[mmadson]

Hi @spier! Thanks so much for starting this conversation and apologies for taking so long to respond. I've since departed Intuit and as such am no longer working on their InnerSource initiatives. I do think this tool is well suited to help realize the Standard Base Documentation Pattern as that's pretty much how we were using it prior to my departure.

It was in use primarily as a reporting tool, to scan our internal github repositories and generate reports for each repository as to how closely the repository adhered to our team's recommended standard documentation structure. We also started to build out the ability for the tool to generate skeleton documentation which teams could then fill out with their details. As far as the challenges that we encountered, I'm not so sure we had a lot of pushback on adopting the standard base documentation -- most of the concerns we encountered were with difficulties making time and space for InnerSource contributions and worrying about code quality from external contributors.

@shagunBose who I believe still works at Intuit may be able to share more insights and how this tool and it's usage has evolved since my departure; especially considering she played and outsized role in working with teams to help them adopt the standard documentation and would have first hand experience to hear any concerns that were raised.

[spier]

Thanks for the additional background @mmadson.

@shagunBose I would love to hear more about the current status of the tool.

We could also explore how to link from the InnerSource pattern (mentioned at the start of this thread) to your tool, which could help to increase adoption external to Inuit.

[spier]

Just want to add there there is another draft pattern here that also uses the term "InnerSource readiness":
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/good-first-project.md

However while your scanner here seems to be focusing on certain documentation being in place, that pattern takes other factors into account that are harder to evaluate automatically (if at all).