From bc09539f0db25e710b32f9e7febd6b644b5bb9a6 Mon Sep 17 00:00:00 2001 From: shrutibist <113216610+shrutibist@users.noreply.github.com> Date: Thu, 20 Aug 2026 20:28:51 -0700 Subject: [PATCH 1/4] Add files via upload --- .../discovering-cross-team-success-stories.md | 123 ++++++++++++++++++ .../sponsor-amplified-evangelism.md | 117 +++++++++++++++++ 2 files changed, 240 insertions(+) create mode 100644 patterns/2-structured/discovering-cross-team-success-stories.md create mode 100644 patterns/2-structured/sponsor-amplified-evangelism.md diff --git a/patterns/2-structured/discovering-cross-team-success-stories.md b/patterns/2-structured/discovering-cross-team-success-stories.md new file mode 100644 index 000000000..59430e693 --- /dev/null +++ b/patterns/2-structured/discovering-cross-team-success-stories.md @@ -0,0 +1,123 @@ +## Title + +Discovering Cross-Team Success Stories + +## Patlet + +Once an InnerSource program has scaled to hundreds of projects and many participating teams, it becomes impossible to know, just by asking around, which of those projects have real cross-team collaboration happening versus visibility alone. Programmatically compare each InnerSource repository's contributors against the org's team or business-unit directory to flag contributions from outside the owning team, then follow up on the flagged cases to confirm and understand the collaboration, turning a scale problem into a systematic way of finding genuine success stories worth telling. + +## Problem + +An InnerSource program's early success is often measured by adoption: how many repositories have been made InnerSource-visible, how many projects are listed in the portal. But visibility alone does not mean collaboration is actually happening. A repository can be perfectly discoverable and still receive contributions from nobody outside its own team. + +At a small scale, a program team can informally track which projects have real cross-team activity simply by asking around or staying close to a handful of visible efforts. Once the program has scaled to hundreds of InnerSource repositories and many participating teams, that informal approach breaks down entirely. There are too many projects and too many teams to track by word of mouth, and asking every team individually does not scale either. Without a systematic way to find where real collaboration is happening, the program loses its best source of evidence, concrete, specific success stories, at exactly the point in its growth when it most needs them to justify continued investment and demonstrate impact to sponsors and the wider organization. + +## Story + +An InnerSource program at a large enterprise technology company had scaled to several hundred InnerSource repositories across many participating teams. The program team wanted to know whether real cross-team collaboration was actually happening as a result, not just repository visibility, but asking around was no longer practical at that scale. + +The team wrote a script to pull contributor data from InnerSource repositories and cross-reference each contributor's identity against the org's team or business-unit mapping. Any contribution from someone outside the repository's own owning team was flagged. This produced a short, manageable list of specific, concrete instances of cross-team activity, rather than an unmanageable pile of raw contribution data or a vague sense that "some collaboration is probably happening somewhere." + +The program team then reached out directly to the flagged contributors and repository owners to understand the nature of each case. Some turned out to be organic, unplanned contributions. Others were the result of two business units with genuinely overlapping needs deliberately choosing to collaborate through the InnerSource repository. Either way, these conversations produced the specific detail (who, why, what problem, what outcome) needed to turn a flagged data point into an actual success story, the same kind of story later used in sponsor readouts and shared more broadly as part of the program's evangelism efforts. + +## Context + +* The InnerSource program has scaled to a large number of repositories and participating teams, large enough that informally tracking collaboration by word of mouth is no longer feasible. +* Contribution activity (commits, pull requests, or equivalent) on InnerSource repositories is available in a form that can be queried or extracted programmatically. +* The organization has some existing directory or mapping of individuals to their team or business unit (an org chart, HR system, or internal directory) that can be used to determine a contributor's home team. +* The program wants to identify not just that collaboration is happening, but specific, concrete instances detailed enough to serve as evidence for sponsors and as case studies for broader promotion. +* Not all flagged cross-team activity is equally meaningful; some may be incidental (a one-off typo fix) rather than a genuine collaboration worth telling as a story. + +## Forces + +* **Manual awareness vs. programmatic detection:** asking teams directly is more contextual and often surfaces detail a script cannot, but it does not scale once the number of repositories and teams grows large; a script scales but only produces a signal, not the full story. +* **Signal vs. noise:** flagging any contribution from outside the owning team is simple to implement, but not every flagged case represents meaningful collaboration; some manual triage is needed to separate incidental contributions from genuine cross-team work. +* **Automation effort vs. ongoing value:** building and maintaining the script and the contributor-to-team mapping takes upfront and ongoing engineering effort, but pays off repeatedly as the program continues to scale, unlike a one-time manual survey that goes stale immediately. +* **Privacy and framing vs. usefulness:** using contributor identity data to flag individuals' activity is useful for the program, but should be framed and used carefully, as a way to find and celebrate collaboration, not as a surveillance or performance-monitoring mechanism. +* **Breadth of coverage vs. depth of understanding:** a script can scan every repository in the program, but understanding why a flagged case matters, and whether it was organic or a deliberate response to shared business needs, still requires a human conversation with the people involved. + +## Sketch + +``` + Hundreds of InnerSource repos, many teams + (too many to track by asking around) + │ + ▼ + ┌──────────────────────────────────────────┐ + │ Script: pull contributors per repo, │ + │ map each contributor to their team/BU │ + │ via org directory │ + └──────────────────────────────────────────┘ + │ + ▼ + Flag: contributor's team ≠ + repository's owning team + │ + ▼ + ┌──────────────────────────────────────────┐ + │ Manual follow-up: reach out to confirm │ + │ and understand the nature of the │ + │ collaboration (organic vs. deliberate) │ + └──────────────────────────────────────────┘ + │ + ▼ + Concrete, specific success story + → sponsor readouts, evangelism, portal +``` + +## Solutions + +Replace informal, ask-around discovery of cross-team collaboration with a programmatic scan of contribution data against the org's team structure, then follow up manually on what the scan surfaces. + +**1. Establish a contributor-to-team mapping.** Use whatever directory the organization already maintains (an org chart, HR system, or internal people directory) to determine which team or business unit each individual contributor belongs to. This mapping is the foundation the rest of the detection depends on, and it needs to be kept reasonably current as teams reorganize. + +**2. Script the comparison against each InnerSource repository's contributors.** Pull the list of contributors (via commit history, pull request authorship, or equivalent) for each InnerSource repository, and compare each contributor's mapped team against the repository's own owning team. Flag any contributor whose team does not match the repository's owning team. + +**3. Treat the flagged list as a lead list, not a finished result.** The output of the script is a manageable set of specific, concrete candidates for further investigation, not a final answer about collaboration quality. Some flagged cases will be trivial (an incidental one-line fix); others will be substantial, ongoing collaboration. + +**4. Follow up directly with the people involved.** Reach out to the flagged contributor and the repository's owning team to understand the nature of the activity: whether it was organic and unplanned, or a deliberate collaboration arising from two teams' overlapping needs. This conversation is what turns a data point into a story with enough specific detail (who, why, what problem, what outcome) to actually be useful. + +**5. Feed confirmed stories into existing sponsor and evangelism channels.** Route the resulting case studies into the program's sponsor readouts and broader evangelism efforts (see the companion patterns on sponsor communication and sponsor-amplified evangelism) as concrete, specific evidence of the program's impact, rather than only aggregate metrics. + +## Resulting Context + +The program gains a systematic, repeatable way to find real, specific instances of cross-team collaboration at a scale where informal awareness alone is no longer possible. + +* **The program can distinguish visibility from collaboration.** Repository counts and portal traffic show that projects are discoverable; this practice shows whether people are actually working across team boundaries because of that discoverability. +* **Case studies become concrete and specific rather than generic.** A story built from a real, confirmed instance ("Team A's request-retry library was adopted and extended by Team B, who needed the same capability for an unrelated product") is far more persuasive to sponsors and to the wider organization than a general claim that "collaboration is happening." +* **The detection method scales with the program.** Once the script and mapping exist, scanning a growing number of repositories costs comparatively little additional effort, unlike an ask-around approach that gets harder as the program grows, not easier. +* **Some flagged cases reveal previously invisible, deliberate collaboration.** Cases where two business units chose to collaborate through an InnerSource repository specifically because their needs overlapped are valuable evidence that the program is enabling collaboration the organization would not have achieved otherwise, distinct from purely organic, incidental contributions. + +This solution introduces a few things to manage deliberately: the contributor-to-team mapping needs periodic upkeep as people and teams change, or the script's flags become unreliable; every flagged case still requires a human conversation to confirm and understand, so the practice does not eliminate manual effort, it focuses it on the cases most likely to be worthwhile; and using individual contribution data this way should be handled and communicated carefully, so it is understood as a way to find and celebrate collaboration rather than as monitoring individual activity. + +## Rationale + +The pattern works because it replaces an approach that does not scale (asking around, staying close to a handful of visible projects) with one whose cost grows much more slowly than the number of repositories and teams involved. Once a contributor-to-team mapping exists, comparing contributors against owning teams is a mechanical operation that can run across an arbitrarily large set of repositories, which is exactly the property an ask-around approach lacks. + +The practice also correctly separates two different problems: finding candidates, and understanding them. The script's output is deliberately treated as a lead list rather than a finished result, because a contributor-to-team mismatch is a strong signal that something worth investigating happened, but not, by itself, evidence of a story worth telling. Reaching out to confirm and understand each flagged case is what supplies the specific detail, who was involved, why, what problem it solved, that makes a case study concrete and credible rather than a vague claim. Feeding the resulting stories directly into the sponsor readout and evangelism practices closes the loop: this pattern is what supplies those other practices with genuine, specific material to work with, rather than leaving them to rely only on aggregate metrics. + +## Related Patterns + +* [Sponsor Communication and Engagement](sponsor-communication-and-engagement.md): the case studies this pattern surfaces are a direct input to the sponsor readouts described in that pattern, giving sponsors concrete, specific evidence of the program's impact rather than only aggregate metrics. +* [Sponsor-Amplified Evangelism](sponsor-amplified-evangelism.md): confirmed success stories from this pattern are exactly the kind of concrete material that makes a sponsor's cue, and the broader evangelism effort, credible and specific rather than generic. +* [Introducing Metrics in InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md): addresses the broader need for concrete metrics to justify and understand an InnerSource program. This pattern is a specific, applied technique for generating one particularly persuasive kind of evidence, individual, confirmed collaboration stories, rather than aggregate statistics alone. +* [Repository Activity Score](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/repository-activity-score.md): provides a numeric measure of a repository's overall activity. This pattern is a complementary, more targeted technique aimed specifically at detecting cross-team activity rather than activity in general. +* [Code Consumers](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/code-consumers.md): addresses the related problem of losing visibility into who consumes a team's shared code once it is opened for InnerSource reuse. This pattern applies a similar programmatic-detection approach, but to code contribution rather than consumption, and for the purpose of surfacing stories rather than managing deprecation or vulnerability communication. +* [Cross-Team Project Valuation](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/crossteam-project-valuation.md): addresses articulating the value of cross-team InnerSource projects in a data-driven way. This pattern supplies one concrete source of the underlying evidence, confirmed instances of real cross-team contribution, that a data-driven valuation could draw on. +* [Praise Participants](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/praise-participants.md): addresses recognizing and thanking contributors once they are identified. The follow-up conversations in this pattern are a natural moment to also apply that pattern's recognition practices with the specific contributors this pattern surfaces. + +## Known Instances + +A large enterprise technology company used this practice once its InnerSource program had scaled to several hundred repositories across many participating teams. The program team wrote a script that pulled contributor data from InnerSource repositories and mapped each contributor to their business unit using the organization's existing directory, flagging any contribution from someone outside the repository's owning business unit. The team followed up directly on flagged cases to confirm and understand the nature of the collaboration, distinguishing organic contributions from deliberate collaboration driven by two business units' overlapping needs. Confirmed cases became case studies used in sponsor readouts and in the program's broader efforts to promote InnerSource across the company. + +## Status + +Structured + +## Author(s) + +Shruti Bist + +## Alias + +Cross-Team Contribution Mining diff --git a/patterns/2-structured/sponsor-amplified-evangelism.md b/patterns/2-structured/sponsor-amplified-evangelism.md new file mode 100644 index 000000000..55a78effc --- /dev/null +++ b/patterns/2-structured/sponsor-amplified-evangelism.md @@ -0,0 +1,117 @@ +## Title + +Sponsor-Amplified Evangelism + +## Patlet + +An InnerSource program cannot reach broad, organization-wide awareness through its own team's channels alone. Direct outreach (roadshows, tech talks, a portal) only reaches the people already paying attention. Equip the program's sponsors with a simple, ready-to-share link and a natural cue for when to mention it, and align the program's message to organizational goals already on their agenda, so sponsors amplify the program into meetings and audiences the program team could never reach directly, turning each sponsor into a distribution channel rather than only a funding source. + +## Problem + +An InnerSource program's own team can run roadshows, give tech talks, and maintain a portal, but these channels only reach people who already attend those sessions or already know to look. In a large, decentralized organization, most engineering teams and their leadership never cross paths with the program's direct outreach at all. + +Sponsors, by contrast, already have standing access to audiences the program team does not: their own monthly staff meetings, their business unit's all-hands, and executive readouts. But sponsors will not spontaneously know when or how to mention the program in their own meetings, and asking them to improvise a pitch on the spot is a poor use of their limited attention and carries the risk of an inconsistent or inaccurate message. Left unaddressed, sponsors' organizational reach goes largely untapped, and the program's visibility stays capped at whatever its own direct channels can achieve. + +## Story + +An InnerSource program at a large enterprise technology company ran its own direct outreach, roadshows and tech talks, but noticed these only ever reached people already somewhat aware of the program. During the program's quarterly sponsor readouts (see the companion pattern on sponsor communication), the program manager began explicitly planning, with each sponsor, where and how they could mention InnerSource in their own upcoming meetings: a monthly staff meeting, a business-unit all-hands, or an executive readout. Rather than leaving this to chance, the program manager gave sponsors a specific cue, tied to an organizational goal already on the sponsor's own agenda, and a single simple link: the InnerSource portal, which doubled as both a repository of active projects and a "how to get started" landing page. + +Depending on the sponsor's preference, the program team either attended the meeting and dropped the link directly into the chat at the right moment, or the sponsor mentioned it themselves and shared the link on the program's behalf. Portal traffic was tracked and consistently showed a clear spike immediately following any of these meetings, direct evidence that sponsor-amplified mentions reached people the program's own channels had not. + +## Context + +* An InnerSource program has direct outreach channels of its own (roadshows, tech talks, an internal portal) but these reach only a limited, self-selecting audience. +* The program has an identified group of sponsors (see Sponsor Communication and Engagement) who hold standing, recurring access to audiences of their own: staff meetings, business-unit all-hands, executive readouts. +* Sponsors are generally supportive of the program but are not going to independently identify the best moment or framing to mention it in their own meetings without help. +* The organization has broader strategic goals or priorities that sponsors are already accountable for communicating in their own meetings, giving a natural hook for connecting InnerSource to something already on the agenda. +* The program has a single, simple, shareable resource (such as a portal link) that works both as a landing page for the curious and a directory for people ready to act. + +## Forces + +* **Program reach vs. sponsor bandwidth:** the program wants maximum organizational visibility, but sponsors have limited time and will not adopt a heavy or complicated ask. +* **Consistency of message vs. sponsor autonomy:** a scripted, precise message is easier to control and less likely to be garbled in retelling, but sponsors are more credible and natural when they can put the message in their own words tied to their own goals. +* **Direct program presence vs. sponsor-delivered message:** having the program team personally present or drop the link in chat guarantees accuracy, but relying only on that limits scale to however many meetings the program team can physically attend; a sponsor delivering the message themselves scales further but trades some control for reach. +* **Simplicity vs. completeness:** a single, simple link is far more likely to be shared and clicked than a longer explanation or multiple resources, but a single link must be good enough to serve very different audiences (the curious newcomer and the ready-to-contribute engineer) at once. +* **Opportunistic timing vs. planning overhead:** waiting for sponsors to organically find the right moment rarely happens, but planning specific cues for specific upcoming meetings takes deliberate, recurring coordination effort from the program team. + +## Sketch + +``` + Program's own channels Sponsor's own channels + (roadshows, tech talks, (staff meetings, BU all-hands, + portal outreach) executive readouts) + │ │ + │ reaches only people │ reaches audiences the + │ already paying attention │ program team can't access + ▼ ▼ + ┌─────────────────────────────────────────────────┐ + │ At sponsor readout: identify upcoming meeting, │ + │ agree on cue (tied to org goal) + portal link │ + └─────────────────────────────────────────────────┘ + │ + ┌───────────┴───────────┐ + ▼ ▼ + Program team attends Sponsor delivers + and drops link in chat message themselves + │ │ + └───────────┬───────────┘ + ▼ + Portal traffic spike + (feedback signal) +``` + +## Solutions + +Turn each sponsor's existing meetings into a distribution channel for the program, by planning specific, low-effort asks in advance rather than hoping sponsors improvise on their own. + +**1. Use the sponsor readout as the planning venue.** During the program's recurring sponsor readouts, explicitly ask each sponsor what meetings they have coming up (their own staff meeting, a BU all-hands, an executive readout) where InnerSource could naturally fit. This turns a general ask for "evangelism" into a specific, scheduled opportunity rather than an open-ended favor. + +**2. Tie the message to an organizational goal already on the sponsor's agenda.** Rather than asking a sponsor to introduce InnerSource as a standalone topic, connect it to whatever strategic priority or goal the sponsor is already planning to discuss. A message that reinforces something the audience already expects to hear about is far more likely to land and far easier for the sponsor to deliver naturally. + +**3. Give sponsors one simple, dual-purpose link.** Provide a single resource, such as an InnerSource portal link, that serves both as a landing page explaining how to get started and a directory of active projects to browse. A single link is easy for a sponsor to remember, say out loud, or paste into chat; multiple links or a longer explanation are not. + +**4. Offer two delivery modes and let the sponsor choose.** Some sponsors are comfortable delivering the message themselves and sharing the link on the program's behalf; others prefer the program team to attend the meeting directly and post the link into the chat at the right moment. Supporting both keeps the ask low-effort for sponsors while preserving accuracy when they want the extra support. + +**5. Track the resulting portal traffic.** Monitor portal visits around the date and time of each sponsor-amplified mention. A visible spike immediately following the meeting is both feedback that the channel is working and concrete evidence to bring back to sponsors and the program's own leadership about the value of their advocacy. + +## Resulting Context + +The InnerSource program gains visibility in audiences its own direct channels could never reach, without requiring sponsors to invest significant time or improvise a message on the spot. + +* **The program's reach compounds through its sponsors' organizational position.** Each sponsor's regular meetings become an extension of the program's own outreach, multiplying the program's effective audience without multiplying the program team's own workload. +* **Sponsors get a low-effort, high-credibility way to actively support the program.** Rather than a vague request to "spread the word," sponsors receive a specific cue and a single link, which is easy to act on and reinforces the value of the readout relationship described in the companion sponsor communication pattern. +* **Portal traffic becomes a feedback loop, not just a vanity metric.** Correlating visible spikes with specific sponsor-amplified moments gives the program team clear evidence of what is working, and clear evidence to bring back to sponsors themselves and the program's own leadership. +* **The message stays connected to what the organization already cares about.** Anchoring the ask to a sponsor's existing goals, rather than treating InnerSource as an unrelated add-on topic, keeps the program's visibility tied to organizational priorities instead of feeling like a separate campaign competing for attention. + +This solution introduces a few things to manage deliberately: identifying the right upcoming meeting and cue for each sponsor takes real, recurring coordination effort from the program team, on top of running the readout itself; a single portal link only works if the portal itself is genuinely useful and current, a stale or confusing landing page will undercut every mention driving traffic to it; and over-relying on this channel without also investing in the program's own direct outreach risks making visibility entirely dependent on sponsor turnover and availability. + +## Rationale + +The pattern works because it treats sponsors as a distribution channel, not only a funding and governance relationship. Sponsors already have standing, credible access to audiences the program team structurally cannot reach on its own, staff meetings, BU all-hands, executive readouts, but that access goes untapped unless someone identifies the specific, low-effort moment to use it. Planning the cue during the sponsor readout, rather than hoping sponsors find the moment themselves, converts a vague aspiration ("get the word out") into a concrete, scheduled action, which is far more likely to actually happen. + +Tying the message to a goal already on the sponsor's agenda and reducing the ask to a single, simple link both serve the same underlying purpose: minimizing the friction between a sponsor's willingness to help and their actual capacity to do so. A sponsor who has to construct an unrelated pitch, or remember multiple resources, is less likely to follow through than one being asked to mention one link in service of something they were already going to talk about. Tracking portal traffic closes the loop, turning what could be an act of faith (sponsors are helping, we assume) into something the program can measure and use to reinforce the sponsor relationship itself, showing sponsors concretely that their advocacy worked is, in turn, more likely to make them willing to do it again. + +## Related Patterns + +* [Sponsor Communication and Engagement](sponsor-communication-and-engagement.md): the sponsor readout described in that pattern is the planning venue this pattern relies on to identify specific evangelism opportunities with each sponsor; this pattern is a direct, tested extension of that relationship into program-wide visibility. +* [InnerSource Portal](https://patterns.innersourcecommons.org/p/innersource-portal): provides the underlying discovery tool that this pattern's single shareable link points to. The Portal pattern addresses building the resource itself; this pattern addresses actively distributing awareness of it through sponsors, beyond what a portal launch's own communications campaign would reach. +* [InnerSource Portal - Hygiene](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-portal-hygiene.md): keeping the portal's project listings current and credible matters directly to this pattern, since sponsor-driven traffic spikes are only valuable if the destination page holds up to scrutiny. +* [Crossing the InnerSource Chasm](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/crossing-chasm.md): addresses the broader strategic challenge of adoption slowing once early adopters are exhausted. Sponsor-amplified evangelism is one concrete tactic for reaching the wider, less self-selecting audience that pattern describes needing different outreach methods for. +* [InnerSource as a Career Booster](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-as-career-booster.md): a message a sponsor could plausibly deliver as part of their own meeting cue, connecting individual career benefit to the organizational goal already being discussed. +* [Introducing Metrics in InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md): the portal-traffic tracking in this pattern is a specific, applied instance of the broader practice of using metrics to demonstrate and justify InnerSource program value. + +## Known Instances + +A large enterprise technology company used this practice as part of its CTO-funded InnerSource program. During quarterly sponsor readouts, the program manager worked with each sponsor to identify an upcoming meeting (a monthly staff meeting, a business-unit all-hands, or an executive readout) and a specific cue tied to an organizational goal already on that meeting's agenda. Depending on the sponsor's preference, the program team either attended the meeting and posted the InnerSource portal link into the chat, or the sponsor delivered the message and shared the link themselves. The program consistently observed a measurable spike in portal traffic immediately following these sponsor-amplified mentions, confirming the channel reached audiences the program's own direct outreach (roadshows and tech talks) had not. + +## Status + +Structured + +## Author(s) + +Shruti Bist + +## Alias + +Sponsor-Driven Program Visibility From f1e09d43b8db2e792e2a13550f4846efc9243711 Mon Sep 17 00:00:00 2001 From: shrutibist <113216610+shrutibist@users.noreply.github.com> Date: Thu, 20 Aug 2026 21:11:17 -0700 Subject: [PATCH 2/4] Update sponsor-amplified-evangelism.md --- patterns/2-structured/sponsor-amplified-evangelism.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/sponsor-amplified-evangelism.md b/patterns/2-structured/sponsor-amplified-evangelism.md index 55a78effc..29b45dc56 100644 --- a/patterns/2-structured/sponsor-amplified-evangelism.md +++ b/patterns/2-structured/sponsor-amplified-evangelism.md @@ -93,7 +93,7 @@ Tying the message to a goal already on the sponsor's agenda and reducing the ask ## Related Patterns -* [Sponsor Communication and Engagement](sponsor-communication-and-engagement.md): the sponsor readout described in that pattern is the planning venue this pattern relies on to identify specific evangelism opportunities with each sponsor; this pattern is a direct, tested extension of that relationship into program-wide visibility. +* Sponsor Communication and Engagement (proposed in [PR #931](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/931), pending review): the sponsor readout described in that pattern is the planning venue this pattern relies on to identify specific evangelism opportunities with each sponsor; this pattern is a direct, tested extension of that relationship into program-wide visibility. * [InnerSource Portal](https://patterns.innersourcecommons.org/p/innersource-portal): provides the underlying discovery tool that this pattern's single shareable link points to. The Portal pattern addresses building the resource itself; this pattern addresses actively distributing awareness of it through sponsors, beyond what a portal launch's own communications campaign would reach. * [InnerSource Portal - Hygiene](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-portal-hygiene.md): keeping the portal's project listings current and credible matters directly to this pattern, since sponsor-driven traffic spikes are only valuable if the destination page holds up to scrutiny. * [Crossing the InnerSource Chasm](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/crossing-chasm.md): addresses the broader strategic challenge of adoption slowing once early adopters are exhausted. Sponsor-amplified evangelism is one concrete tactic for reaching the wider, less self-selecting audience that pattern describes needing different outreach methods for. From d815f7a22df79a37bf5fa3fa42f8e143a71bd33d Mon Sep 17 00:00:00 2001 From: shrutibist <113216610+shrutibist@users.noreply.github.com> Date: Thu, 20 Aug 2026 21:12:57 -0700 Subject: [PATCH 3/4] Update discovering-cross-team-success-stories.md --- patterns/2-structured/discovering-cross-team-success-stories.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/discovering-cross-team-success-stories.md b/patterns/2-structured/discovering-cross-team-success-stories.md index 59430e693..9e7037e26 100644 --- a/patterns/2-structured/discovering-cross-team-success-stories.md +++ b/patterns/2-structured/discovering-cross-team-success-stories.md @@ -98,7 +98,7 @@ The practice also correctly separates two different problems: finding candidates ## Related Patterns -* [Sponsor Communication and Engagement](sponsor-communication-and-engagement.md): the case studies this pattern surfaces are a direct input to the sponsor readouts described in that pattern, giving sponsors concrete, specific evidence of the program's impact rather than only aggregate metrics. +* Sponsor Communication and Engagement (proposed in [PR #931](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/931), pending review): the case studies this pattern surfaces are a direct input to the sponsor readouts described in that pattern, giving sponsors concrete, specific evidence of the program's impact rather than only aggregate metrics. * [Sponsor-Amplified Evangelism](sponsor-amplified-evangelism.md): confirmed success stories from this pattern are exactly the kind of concrete material that makes a sponsor's cue, and the broader evangelism effort, credible and specific rather than generic. * [Introducing Metrics in InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/introducing-metrics-in-innersource.md): addresses the broader need for concrete metrics to justify and understand an InnerSource program. This pattern is a specific, applied technique for generating one particularly persuasive kind of evidence, individual, confirmed collaboration stories, rather than aggregate statistics alone. * [Repository Activity Score](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/2-structured/repository-activity-score.md): provides a numeric measure of a repository's overall activity. This pattern is a complementary, more targeted technique aimed specifically at detecting cross-team activity rather than activity in general. From 4afc9e198991511533a69e914e259392d98f5ff4 Mon Sep 17 00:00:00 2001 From: shrutibist <113216610+shrutibist@users.noreply.github.com> Date: Thu, 20 Aug 2026 21:20:24 -0700 Subject: [PATCH 4/4] Update README.md --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 5067007c6..92e9d680c 100644 --- a/README.md +++ b/README.md @@ -60,6 +60,8 @@ Our mission * [Group Support](patterns/2-structured/group-support.md) - *What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.* * [Explicit Governance Levels](patterns/2-structured/governance-levels.md) - *Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.* * [InnerSource Hackathon](patterns/2-structured/innersource-hackathon.md) - *Only InnerSource enthusiasts practice InnerSource during the early stages of adoption, while most engineering teams lack the time or motivation to try it. Hosting a company-wide hackathon focused on InnerSource contributions provides a safe space for engineers to experiment with InnerSource practices and produces tangible contributions to InnerSource projects.* +* [Sponsor-Amplified Evangelism](patterns/2-structured/sponsor-amplified-evangelism.md) - *An InnerSource program cannot reach broad, organization-wide awareness through its own team's channels alone. Direct outreach (roadshows, tech talks, a portal) only reaches the people already paying attention. Equip the program's sponsors with a simple, ready-to-share link and a natural cue for when to mention it, and align the program's message to organizational goals already on their agenda, so sponsors amplify the program into meetings and audiences the program team could never reach directly, turning each sponsor into a distribution channel rather than only a funding source.* +* [Discovering Cross-Team Success Stories](patterns/2-structured/discovering-cross-team-success-stories.md) - *Once an InnerSource program has scaled to hundreds of projects and many participating teams, it becomes impossible to know, just by asking around, which of those projects have real cross-team collaboration happening versus visibility alone. Programmatically compare each InnerSource repository's contributors against the org's team or business-unit directory to flag contributions from outside the owning team, then follow up on the flagged cases to confirm and understand the collaboration, turning a scale problem into a systematic way of finding genuine success stories worth telling.* ### Maturity Level 1: Initial