# Enterprise open-source participation needs policy and training scaffolding Qualcomm's shift from closed to collaborative development hinged on a non-technical precondition: deciding "how do we show up as Qualcomm in the open community?" and putting the **policies and training** in place to let developers participate. A large enterprise can't simply open a repo; the cultural and legal scaffolding (what employees may contribute, how, under what review) is the gating work. <!-- atomicity: 1 idea ✓ --> ## Scope & conditions - Holds for enterprise adoption of open-source development practices, where legal and organizational constraints shape whether employees can contribute upstream. ## Links - [[3. Resources/Permanent Notes/Stewardship Invests in Contributor Capacity Not Just Cash]] — policy and training are concrete investments in a contributor's ability to participate. - [[3. Resources/Permanent Notes/Coerced Contribution Kills the Commons]] — contrasts voluntary, supported participation with contribution demanded without agency or support. - [[3. Resources/Literature Notes/Open Source Projects in Enterprise Settings]] — supplies a broader roadmap of compliance, mentorship, infrastructure, and lightweight approval practices. - [[3. Resources/Literature Notes/Open Source Software in Enterprise Ecology]] — places this scaffolding inside the wider system-integration problem enterprises face. - [[3. Resources/Literature Notes/Open Source in Enterprise Development]] — evidence-for: enterprise adoption of iterative open-source methods depends on organizational permission to experiment and collaborate. - [[3. Resources/MOCs/Open Source Governance MOC]] — applies-in: the MOC lists this note under Synthesis additions (2026-06-11). ## Source - [[3. Resources/Readwise/Articles/From Closed to Collaborative Lessons From Qualcomm’s Open Development Experience - Rashmi Chitrakar|From Closed to Collaborative — Qualcomm]]