InnerSource Maturity Model?

[brooklynrob]

All,

I wanted to ask if anyone has developed or come across an inner source maturity model.

Specifically I am looking for something that could be used to evaluate internal projects across multiple relevant dimensions to assess the degree to which a project is already demonstrating attributes and capabilities needed to effectively "do inner source" (perhaps w/o the project team even having known what inner source is -- e.g., perhaps they already work to a "public" roadmap within the 4 walls of their organization.)

I was thinking (and might argue that) these dimensions might be similar to those that @mindthegab, @copiesofcopies, @pmonks and I used a few years back to build the FINOS board report and health check rubric, but perhaps not.

Again, use of the model would be the assess projects inner source readiness across 6-8 dimensions, and an associated rubric.

Thanks,

Rob
rob(at)ttmadvisors(dot)com

[amaltson]

Hey @brooklynrob that's a really great question. I personally haven't seen anything in my experience personally. Perhaps this would be a great project for this SIG to work on? We could pool our varied experiences and see if we can create a common maturity model. The model should provide a baseline and guide organizations to build on it for their own use cases.

That rubric might be a good scaffold to build on, but I think we'd need to tailor it. Ideally we have levels of maturity that are encouraging at any level, I wouldn't want organizations to feel they have to be at the highest maturity level and feel discouraged when it's challenging to get there. Adoption could be encouraged by having organizations share what level some of their products are at. It'd also provide us insights where the SIG could focus on.

Anywho, love the idea!

[Ludmila-N]

There are a few InnerSource maturity models out there.
This one for example:
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/a9e136eb57fd927c12ee27827e35cd7215226e53/patterns/2-structured/maturity-model.md

[mcleo-d]

Thanks so much @Ludmila-N 🚀

The InnerSource SIG is meeting Wednesday, 14 April 2021 - 10am EST / 3pm UK if you would like to comment on the agenda below and join the call as I'm sure this issue will be raised?

#10

cc @finos/innersource-maintainers

[daniela-g-zheleva-db]

There are a few InnerSource maturity models out there.
This one for example:
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/a9e136eb57fd927c12ee27827e35cd7215226e53/patterns/2-structured/maturity-model.md

Thank you for sharing these! Perhaps it would be useful for us to try pilot this (or another maturity model) with our inner source communities within our organisations. By doing this we can provide feedback on the pattern as well as a 'guide' / tips on how others can do the same.

Just a thought.

[brooklynrob]

• @Ludmila-N who pointed to the same model.

Some really good stuff here. Thanks for point this out.

Question... I don't see anything explicit about use a backlog (e.g., Github Issues, JIRA items), decomposing and describing work items in a small grain size that in turn form the basis of the backlog, prioritizing what's on the backlog and aligning to the overall roadmap (and customer /user feedback -- e.g., prioritizing a critical bug fix over an inflight new feature), and flagging backlog items as "good first issues" and/or "help wanteds". I recognize those are also separate things, but they are related -- overall idea is backlog stewardship. Is that implicit in other sections? Something people chose not to include for a reason? Maybe something to add?

[Ludmila-N]

I agree that the published model does not cover software engineering decisions, which is why we needed a different model for practical use. And why we need this discussion :)

[mcleo-d]

Hey @daniela-g-zheleva-db - What are your thoughts on making this issue the first InnerSource GitHub Discussion. Maybe this could be raised in the InnerSource SIG meeting #11 ..? 🤔

[claredillon]

Noting that the minutes for our InnerSource SIG Meeting are now included, where there was an extensive discussion on the topic here: #10

[claredillon]

We're due for a follow up meeting in next SIG Meeting - date TBC

[claredillon]

A sub-group of the SIG have volunteered to create a working draft of a maturity matrix to follow up on this issue. I have attached the draft version which will be discussed at the next scheduled InnerSource SIG meeting on June 7th.

We would welcome comments in the Google doc version here: https://drive.google.com/file/d/1MvmaCwcI30MjlTCoPwKYvL7XdFbLBgzb/view?usp=sharing

For those who cannot access Google docs, I have attached the doc in Excel form. If you have comments you would like to share - please do so in this thread.

FINOS InnerSource Maturity Matrix.xlsx

Some notes on the document:

• In our last discussion, it was agreed that the "Tools & Processes" and "Documentation" sections might benefit from having sub sections with more details. This will be a follow-on action for the working group. In the meantime, we have created some empty lines for those draft sub-sections to allow for comments/suggestions.
• It has been suggested that a good next step in this effort would be to gather (and/or create) examples or recommendations for some of the points listed in the maturity matrix (e.g. SLAs appropriate at different levels) - we welcome any feedback on which resources would be most useful to the SIG.
• Finally, we would like to acknowledge that it has been recognised that it may not be appropriate or possible for some projects to get to level 3, and that is fine in certain contexts.

[mcleo-d]

This is an example comment ...

[mcleo-d]

Hello InnerSource SIG members,

I am pleased to share our progress around the Maturity Matrix with you. I have attached the latest PDF version to this discussion which we'd like your feedback via this thread before Monday 30th August.

Please also state in this thread whether you'd like to be nominated as the Maturity Matrix project maintainer when this piece of work is contributed to FINOS.

We have now locked the document until it can be uploaded into GitHub, following which changes will be controlled through the GitHub PR process.

This decision was taken since it was becoming difficult to edit a Google Sheet document, and GitHub can provide us a better mechanism for reviewing and accepting changes. I would encourage you to review the documents while the logistics of uploading this to GitHub are worked out.

You can find all of the minutes in the GitHub issue #19

Kind regards,

@daniela-g-zheleva-db and @amaltson
3. InnerSource Maturity Matrix - Organization Maturity Matrix.pdf
2. InnerSource Maturity Matrix - Project Maturity Matrix.pdf
1. InnerSource Maturity Matrix - Overview.pdf

[aaronsearle]

@mcleo-d Feel free to include me as a maintainer.

Reviewing this now (apologies I could not attend the original set of meetings), there's some good material in there. Some feedback/comments on the Project Maturity Matrix.

1. The table isn't symmetrical, it doesn't flow well to have areas that don't have a good spread of levels. Either this means there are gaps (this is obviously fine and can be refined), there are too many levels or the sections themselves are too granular. It seems to me there is a combination of all three here.
2. CI & Testing, CD & Building sections don't really align or flow well. This could probably be better expressed as Build, Test and Deploy/Release as distinct sections
3. Development practices and developer onboarding overlap. I'd maybe switch this around and put
4. Overall I think the document would be easier to navigate if the items roughly followed their sequence in the delivery pipeline as someone would see them. So documentation first and visibility first, then local development practices, then testing, then releasing then releasing. Finally governance and leadership.
5. Documentation section should also include absence of documentation at level 0.
6. An anti-pattern or "no materity" level should be added either replacing Level 0 or adding a Level -1, this is useful to highlight techniques that directly oppose innersourcing. Such as, closed repos requiring you to request access, lack of any documentation, inability to test due to lack of access, manual undocumented testing workflows, contributions requirements that are not listed, protracted release schedules or never released anymore.

@mcleo-d did the source documents make their way to github, so that I can provide some of this feedback in the form of PRs?