InnerSourceCommons / InnerSourceCommons/InnerSourcePatterns
Create a plan to level up existing patterns
Offen
@spier arbeitet bereits daran.
Seit 14.5.2025.
- Vorherrschende Sprache
- HTML
- Sterne
- 853
- Forks
- 206
- Ø Merge
- 1 T. 23 Std.
- Gemergte PRs (30 T.)
- 2
Beschreibung
Things that we could do (in random order):
- (priority) promote patterns from Initial to Structured / this would get them published in the book
- Possible organize a hackathon of sort around this?
- Do we need to revisit our Pattern maturity model? (i.e. the Levels 1,2,3)
- Do the content and validation requirements for our patterns still make sense for us? If not, let's change them :)
- See contributor handbook
- See discussion #762
- (later) promote patterns from Structured to Validated
- orphaned patterns / how to create an offloading path for patterns? (i.e. deprecating patterns, no matter what maturity they were at before)
Initial => Structured
1-Initial patterns primed for upgrade to 2-Structured (based on Known Instances only)
| # orgs | pattern | ready to be leveled up? |
|---|---|---|
| 0 | assisted_compliance.md | |
| 0 | bad-weather-for-liftoff.md | |
| 2 | balancing-openness-and-security.md | yes |
| 1 | capacity-for-contributions.md | yes - one more Known Instance would be great |
| 0 | change-the-developers-mindset.md | |
| 0 | change-the-middle-management-mindset.md | |
| 3 | circle-communities.md | |
| 0 | code-consumers.md | |
| 3 | code-of-conduct.md | yes - could be a bit more targeted towards InnerSource |
| 0 | concept-anchor.md | |
| 1 | contained-innersource.md | |
| 1 | creating_an_innersource_strategy.md | |
| 1 | cross-team-retrospectives.md | no - Seems like a relatively obvious practice though, especially in orgs/teams that do team-internal retrospectives anyways. I would expect that we can find more orgs that have used this pattern, without knowing that it exists. |
| 0 | crossing-chasm.md | |
| 0 | cultural-change-through-hiring.md | |
| 0 | defeat-hierarchical-constraints.md | |
| 0 | developer-incentive-alignment-for-innersource-contribution.md | |
| 2 | discover-your-innersource.md | maybe - 2 Known Instances were added. work to level up started in #780 |
| 2 | document-architecture-decisions.md | maybe - pattern was only recently added, without involvement from an author from the orgs mentioned as known instances. would benefit from contributions from other people before leveling it up |
| 0 | duplicated-projects.md | |
| 0 | explicit-shared-ownership.md | |
| 0 | good-first-project.md | |
| 0 | governance-based-project-setup.md | |
| 0 | improve-findability.md | |
| 0 | incentive-mechanisms-for-voluntary-contribution.md | |
| 1 | include-product-owners.md | |
| 1 | incubator-pipeline.md | |
| 3 | innersource-ambassador.md | yes - Siemens is another org that just confirmed that they use something like this. This pattern was partly written by AI. Next steps: a) thorough review by any of the adopting orgs (e.g. SAP) maybe a visual that we can use? |
| 2 | innersource-customer-interview-questions.md | |
| 1 | innersource-guidance-group.md | |
| 1 | innersource-hackathon.md | no - Hackathons are widely adopted at companies. Wondering if we can find more orgs that have used that existing hackathons to increase the InnerSource practice between teams. |
| 0 | innersource-portal-hygiene.md | |
| 0 | internal-developer-platform.md | maybe - one would expect that we can find some known instances for this pattern but so far we have not. also much like the "code of conduct" pattern this one could be more targeted towards InnerSource |
| 1 | introducing-metrics-in-innersource.md | |
| 0 | junkyard-styled-innersourcing.md | |
| 1 | modular-code.md | no - Lack of modularization in the software architecture prevents reuseability. Therefore this pattern seems like a baseline requirement for any InnSource activity. Maybe this is is so basic, that orgs don't even realize that they are actually using this pattern. An extension of this pattern could be to invest even more in modularization, to create more opportunities for reuse (and with that opportunities for InnerSource). |
| 0 | not-invented-here.md | |
| 0 | open-source-trumps-innersource.md | |
| 0 | organizational-mindset-change.md | |
| 0 | overcome-acquisition-based-silos-developer.md | |
| 0 | overcome-acquisition-based-silos-manager.md | |
| 0 | overcoming-project-management-time-pressures.md | |
| 0 | reluctance-to-accept-contributions.md | |
| 0 | share-your-code-to-get-more-done.md | |
| 0 | shared-code-repo-different-from-build-repo.md | |
| 1 | source-code-inventory.md | yes - if we can integrate the working knowledge from Philips, and find one more Known Instance. work started in #779 |
| 0 | sustainable-innersource-program.md | |
| 1 | transitioning-contractor-code-to-innersource-model.md | |
| 3 | walk-the-innersource-talk.md | yes - check the pattern name. shorten patlet. Check the unverified solutions in the pattern. |
Structured => Validated
2-Structured patterns primed for upgrade to 3-Validated (based on Known Instances only)
| # orgs | pattern | ready to be leveled up? |
|---|---|---|
| 4 | 30-day-warranty.md | yes |
| 5 | base-documentation.md | yes |
| 1 | common-requirements.md | |
| 3 | communication-tooling.md | yes |
| 1 | contracted-contributor.md | |
| 3 | core-team.md | yes |
| 1 | crossteam-project-valuation.md | |
| 2 | dedicated-community-leader.md | |
| 3 | document-your-guiding-principles.md | yes |
| 1 | extensions-for-sustainable-growth.md | |
| 3 | gig-marketplace.md | yes |
| 2 | governance-levels.md | maybe - in 3/2025 levelled up to structured - see #765 |
| 1 | group-support.md | |
| 4 | innersource-license.md | yes |
| 5 | innersource-portal.md | yes |
| 1 | issue-tracker.md | |
| 4 | maturity-model.md | yes |
| 2 | praise-participants.md | |
| 2 | release-process.md | |
| 2 | repository-activity-score.md | |
| 1 | review-committee.md | |
| 3 | service-vs-library.md | yes |
| 2 | start-as-experiment.md | |
| 6 | transparent-cross-team-decision-making-using-rfcs.md | yes |
| 4 | trusted-committer.md | yes |
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Bewertung
Dieses Issue wurde noch nicht bewertet.