Proposed Outline for OSPO Book, Second Edition

[semioticrobotic]

At a recent editorial meeting, contributors discussed the organization of a new edition of the OSPO Book. I volunteered to offer a vision for one such organizational framework and am delighted to share it here for community feedback.

In truth, I think the current verison of the book already contains the germ of the next edition's organizing framework. Chapter 1 describes the multiple "directionalities" in which OSPOs typically work, and I believe organizing the book into sections focused on each of these directionalities would be an effective way to structure the book's overall narrative. This has the benefits of:

1. Bringing greater overall coherence to the work as it grows,
2. Helping us identify areas where we can make concrete and valuable improvements, and
3. Providing a framework for assessing incoming ideas for new materials

As the book currently states, OSPOs operate by:

Looking downward: The head of an OSPO must manage the team's tasks effectively. Depending on the OSPO’s objectives, the team’s responsibilities may vary.

Looking upward: If proposing the creation of an OSPO, managing expectations and aligning with executives’ technology needs is necessary.

Looking sideways: Collaboration with other teams is critical. For instance, in business-oriented OSPOs, collaborating with the developer tools and security teams is essential. Another example is an OSPO’s relationship with any InnerSource activities within the organization.

Looking outside: Representing the organization to external communities and foundations is crucial. The integration strategy must align with the organization’s objectives and vision.

Looking downward, upward, sideways, and outside—a nice way to frame the many activities in which OSPOs typically participate (and all the directions in which open source program managers tend to feel themselves pulled each day!).

We might use that framework to help us determine what we'll need to write or curate in order to construct something like a "second edition" (or "v2.0") of the OSPO Book. To that end, I've assessed the book's existing contents and reviewed folks' suggestions for new material (in issues, on Slack, etc.). I've combined all that into an editorial vision for OSPO Book, Second Edition (cue postal horn).

It is as follows:

Introduction: Meet the OSPO
In this section, we introduce the concept of the open source program office and outline the roles it can play in professional organizations. This section introduces the book's organizing framework and previews what's to come.

Chapter	Pre-existing material	New material
Meet the OSPO	✓
The Value of Open Source Program Offices	✓

I believe these pre-existing chapters can be combined and re-written into a single, more cohesive chapter for a more comprehensive introduction.

Looking Downward: Managing an OSPO
In this section, we explore effective and efficient OSPO management, with special attention to operationalization of the mission and carrying out day-to-day activities.

Chapter	Pre-existing material	New material
Creating Your OSPO	✓
Day-to-Day Operations	✓
Tooling & Automation		✓

I believe pre-existing chapters form a solid foundation for this section.

Looking Upward: Aligning with Organizational Strategy
In this section, we explain how to align the OSPO's activities with the organization's overall open source mission, with special attention to open source business strategy, goal-setting, and effective communication with executive sponsors.

Chapter	Pre-existing material	New material
Aligning Open Source Activity with Business Goals		✓
Working with/in Internal Policies		✓

I believe we'll need to do considerable work to flesh this section out in a second edition.

Looking Sideways: Collaborating with Internal Stakeholders
In this section, we offer advice for collaborating with the various teams OSPOs typically support. Emphasis here is on ways the OSPO can be a better facilitator, problem-solver, and partner in cross-functional situations.

Chapter	Pre-existing material	New material
Working with Security Teams (currently called "Managing Open Source Security")	✓
Working with Legal Teams		✓
Working with InnerSource Teams		✓
Developer enablement at scale		✓

I believe we have the seeds of some of this material already present in the first edition.

Looking Outward: Engaging Communities and Foundations
In this section, we discuss the finer points of interacting with third-parties, like external contributor communities and foundations, to ensure the sustainability of the organization's open source mission.

Chapter	Pre-existing material	New material
Community Engagement & Growth		✓
Open Ecosystem Participation		✓
Partnering with Foundations		✓

I don't believe we currently have any of this material in the first edition of the book, but I also confess that I need to do a closer re-reading!

Conclusion: Resources and Appendicies
This final section of the book wraps the overall argument and offers some additional resources for further thinking and engagement.

Chapter	Pre-existing material	New material
What does the future OSPO look like?		✓
Appendix	✓
Case Studies	✓
End User Journeys	✓

I believe we have most of this material already, but I suspect we are always seeking to add more of this kind of thing.

One additional note: I did not include the current chapter called "Using Metrics in Your OSPO" because I would actually advocate for breaking that chapter up and instead adding a standard section on "measuring success" to each chapter (or section) above. This way, discussion of metrics is tied more concretely to the practices and recommendations themselves; readers won't need to "flip" back and forth from a discussion of practice to an appendix on meausuring that practice.

I want to stress that this is just a conversation-starter—something to help us organize our thinking around a new version of the book and better determine "what's in and what's out." So please do push back on it and help shape it by proposing alternative organizational framworks or additional chapter ideas for sections as outlined. I'd love that!

(cc: @alice-sowerby, as discussed!)

[lenucksi]

Here's some assorted comments on the proposal:

Terms

• There's some established terms, mostly from the compliance segments of the field, e.g. outbound (publication, contribution/inbound (consumption) FOSS and the associated processes. I'd propose to keep to not get too creative with regard to creation of new terms as to not increase the cognitive load of those new and existing in the field. It's complicated enough already. In this specific case that would go towards the "look outside" part. Let's look for ways to harmonize that with existing terms. I'd agree with the conceptualization of the directions mostly otherwise.
  • For that regard it might be interesting to take a look at VM Brasseurs recent book (and if only for the TOC): https://www.amazon.de/Business-Success-Open-Source-Strengthen/dp/B0DPBXPPVQ it reflects common established terminology and issues in a reasonable manner.
  • In terms of the alignment with the security teams it might actually be an interesting idea to see what terms from there can be incorporated to enable ability for them to connect. This includes components such as (DF)IR (incident response), ISMS/integrated management system equivalents (your average, working FOSS compliance process often is a more or less distant relative to those). Given the supply chain issues and the current geopolitical environment, these two fields will rather converge more than less I'm afraid.

Directions

• I'd strongly focus on sideways, outside and upward. Most OSPOs are likely not excessively large or staffed with lower seniority people such that pure intra-OSPO coordination dealings are likely not the most burning issue of the day in my experience.

Sideways

• There is no such thing as "InnerSource teams". InnerSource is an activity any given team member can perform with the IP that they or their team holds and a team member of another team.
  • A team can provide a more or less central component that receives a lot of InnerSource contribution requests thus taking up a lot of time processing those and mentoring the contributors. This does not turn this team into an "InnerSource team". It will, however, require substantial FOSS/InnerSource skills in the members of that team.
  • This also brings us to the "sideways" component of HR / corporate structure incentive setting for middle/line managers. Including InnerSource (and open source if outbound activity is in the game) there is of make/break importance.

Outward

• Again attaching to the InnerSource part, this time by way of the "Open Ecosystem Participation":

  • Your average OSPO is more or less powerless when it comes to direct impact at scale regarding prevention of damage or participation in projects. All of this is in the end effected by the actual engineers writing/changing code and to some degree the line managers influencing their incentives and priorities.
  • Thus, especially on the outward trajectory, it is of critical importance that said engineers (and their line managers) have sufficient skills in how to act in the open source environment.
  • InnerSource can act as a training ground to gain some of these skills.

• The same goes for corporate policy addressing the legal aspects of IP ownership in case of outbound participation or hybrid ownership constructions which are usually legal aspects executed in HR/work contract aspects/addenums.

Other takes

Expectation management

• The October call had the take of "why are we having those OSPOs in the first place - not just to justify head count but to achieve certain goals".

• Also, OSPOs come in various sizes (1-150+ people), attachment points in organizations (CTO, CISO, CPrivacy/Risk/LegalO, Innovation Incubators, some bizarre deep down the hierarchy one man attempt, ...) and constructions (virtual, dedicated, distributed but intentional).

• There is usually a way of evolution of said OSPOs (ad-hoc, virtual, dedicated, distributed/embedded + central coordination, ...).

• Certainly not everyone needs to have one, have an ultra-large dedicated one or - flip side - have a micro OSS handling function and expect magic.

• I would find it useful to present the breadth of variation and evolution stages together with the expectable results, weaknesses, achievable & unachievable capabilities and tasks at the various points and the trade-offs between the various attachment points to allow people to calibrate their expectations and jobs to be done.

Learning from failure

There are certain ways that are a more or less safe way to set your company up for failure wrt to FOSS. It might be interesting to present some case studies for some of those to allow people to learn from those without having to pay for the consequences of them. Not sure how to construct this, some hypothetical / constructed cases might help.

Learning Path structure and setup

In the October and November calls it was discussed and saw interest to

• enable educational people (universities etc.) to train FOSS handling skills
• enable different groups in multiple states of prior knowledge and with different learning to profit from the book.

A concept that might be interesting in that regard would be to enable different learning paths:

• Turn each chapter into a (more than less) stand-alone, independently readable segment.
• Put a an addenum of the like "as a person with this background and that interest, read chapters x,y,z in this order".
• It might be required to add some primers / glue material chapters to bring them up to speed. These might either be external material or created material.
• I'll add a new comment below this describing and example approach for this.

[lenucksi]

Caveat: All of this is pure example, generated content to exemplify the idea of the learning path approach.

1) Recommended Learning Paths (Short Form — Chapters in Sequence)

Starting an OSPO — Build & Launch (Goal: a functional starter OSPO)

• Sequence: 1 → 3 → 4 → 6 → (Appendix/Resources)
• Purpose: Decision-making, setup, initial operations, metrics.
• Primary audience: Executives → OSPO leads.

Integrating with Risk & Compliance (Goal: embedding the OSPO into management systems)

• Sequence: 2 → 3 → 5 → 6 → Glue: “Framework Mapping”
• Purpose: Translating OSPO goals into ISMS, COBIT, and GRC vocabulary; compliance flows.
• Primary audience: Legal, compliance, risk teams, CIO/CTO.

Teaching the Fundamentals / Pre-101 (Goal: instructional modules / curriculum components)

• Sequence: (Primer A) → 1 → 2 → 3 → 4 (each chapter with exercises)
• Purpose: Modular curriculum for universities and corporate onboarding programs.
• Primary audience: Educators, trainers, instructional designers.

Day-to-Day Operator (Goal: mastering everyday operational tasks)

• Sequence: 4 → 5 → 6 → (OSPO End-User Journeys)
• Purpose: Issue handling, community engagement, security workflows, metrics.
• Primary audience: OSPO staff, community managers, DevOps teams.

Legal & Supply-Chain Assurance (Goal: compliant usage & supply chain awareness)

• Sequence: 2 → 5 → 3 → Glue: “License + SBOM Primer”
• Purpose: Licensing questions, security integration, third-party software governance.
• Primary audience: Counsel, procurement, SCA teams.

2) Glue / Bridging Chapter Descriptions (Concise / Reusable)

These short bridges (3–8 pages each) slot before, between, or after chapters to support vocabulary alignment and conceptual transfer.

Primer A — Open-Source 101 (Pre-101)

• Content: What OSS is; license basics (permissive vs. copyleft); OSS values; roles (maintainer/contributor). 20–30 min read + 3 exercises. Includes simple examples and a glossary for non-technical readers.

Primer B — Management Vocabulary & Frameworks

• Content: Short comparison of ISO-27001, COBIT, GRC terms, and integrated management systems. Exercise: map one OSPO function to ISO/COBIT controls. Purpose: gives executives and compliance teams a shared language.

Bridge X — From Policy to Operations

• Content: How formal OSS policies translate into tasks, roles, and tools (checklist: Policy → Workflow → Tooling → KPI). Includes templates (Policy → SLA → Playbook).

Bridge Y — License & SBOM Quickstart

• Content: Practical steps for license scanning and SBOM generation, typical toolchains, red flags. Contains a quick audit checklist.

Bridge Z — Community Participation Path

• Content: Steps from observing to contributing to co-maintaining (observe → contribute → co-maintain). Governance patterns for upstream engagement and contributor-onboarding templates.

Each bridge includes: target audience, expected prerequisites, learning objectives, a one-page checklist, two practical exercises, and links to relevant chapters.

3) Front-of-Book Map: How to Use This Guide Modually (Concrete Structure)

Quick-Start One-Pager (Front)

“Which type of reader are you?” (Decision tree: Executive / Legal / Educator / OSPO Operator / New Hire) → directs to one of the five learning paths, including page/chapter numbers and estimated time.

Learning-Path Cards (per path)

A two-page spread per path: sequence (chapter IDs), key chapter objectives, required glue modules, expected outcomes (e.g., “MVP OSPO in 8 weeks”), and readiness/exit criteria.

Chapter Cards (at the start of each chapter)

At a glance: purpose, three core questions, prerequisites, what you will be able to do afterward, suggested exercises.

“Pick-and-Glue” Guide (Front/Back)

Short ruleset: how to assemble chapters as building blocks. Example sequences for a 2-hour workshop, 1-day training, and 8-week curriculum (e.g., Primer A → Chapter 1 → Exercise Set → Bridge X → Case Study).

Appendix: Teaching Pack + Materials

Slide templates, exercises, grading rubrics, slide decks, case studies, checklists, SBOM example, glossary.

End-of-Book: Implementation Playbooks

One-page reference playbooks: “Launch OSPO,” “Onboard Contributor,” “License Incident Response,” “Security Vulnerability Workflow.”

Interactive Supplements (online)

Links to repository materials (GitHub), templates, glossary, and other assets (as already available in v1).

Extension points

One could use this format to extend it past the printed book online with university curricula, material etc.

[alice-sowerby]

@semioticrobotic and @lenucksi thanks for the great start! I will review this as soon as I can. I have a busy week this week as I have several reports to write, but know that it is on my radar.

[semioticrobotic]

Thinking more today about @lenucksi's vision:

A concept that might be interesting in that regard would be to enable different learning paths: Turn each chapter into a (more than less) stand-alone, independently readable segment. Put a an addenum of the like "as a person with this background and that interest, read chapters x,y,z in this order". It might be required to add some primers / glue material chapters to bring them up to speed. These might either be external material or created material.

And it occurs to me that this might be describing what is (or could be, with some additional work) available in the TODO training modules. Which for me raises the question: What is the purview of the book, and what is the purview of the training modules?

Then, just to complicate matters even further: What then is the relationship of all that material to the TODO guides? The guides, for instance, already seem to contain several key materials we've identified as important for the next iteration of the OSPO Book; several of the guides could each serve as a potential chapter in a book-length work.

I've searched but haven't found anything that lays out parameters for each of these "content types" or "content genres." So I think I might need someone with a longer history in the project (@alice-sowerby, @fer-correa, @koozz, etc.) to help me understand the distinctions between them. This way, as we refine the vision for v2, we're not overstepping our territory.

[semioticrobotic]

I think this is great, @alice-sowerby! It gives us a framework for thinking about "what's in and what's out" with respect to not only the book but to all types of contributions. I like this because it provides additional options for directing contributors. If book editors decide they need to say "no" to a contribution that isn't quite a fit for the book, they can at least say "no, but ..." and direct the contributor to the guides or tutorials instead.

So in my mind this looks something like:

• Tutorials: Guides
• How-to guides: Training Modules
• Technical reference: Glossary
• Explanation: Book and Studies

You're more familiar with the taxonomy, however, so I think you're better qualified to do the classification. Once we have a handle on it, we can use it to audit content already "assigned" to one of those types and determine if it's fit for purpose or should be re-used elsewhere (e.g., a guide that works better as a book chapter, etc.). There are so many great resources already available in the ospology project. I think we can maximize their value simply by reorganizing them with more explicit emphasis on the purpose they serve.

Where is the best place to document this schematic so the community can review, comment on, and adopt it?

[alice-sowerby]

I think that we should look to adopt this model of content type within the README of the Ospology repo. So, perhaps a PR along the lines of changing it (or perhaps adding a new .md file to link to from the README).

[alice-sowerby]

@lenucksi 's proposed learning paths model looks to be a holistic approach to including all of these documentation types in the book. There is no right or wrong with this - it's a choice. People make books that can be used in many ways!

However, as OSPOlogy already has a range of content types (and to keep our own scope focused), I lean towards not expanding the book beyond the "Explanation" category. We could consider making the online book the "first class citizen" and plan to heavily integrate it to other online content, with the print book still valuable as a standalone resource.

Keen to hear thoughts :)

[semioticrobotic]

I agree with you, @alice-sowerby, and I like the idea of the OSPO Book serving as the kind of "map" for the rest of the Ospology materials. This helps us articulate a basic strategic approach to creating content and making sure it all works together synergistically (rather than duplicating efforts or creating contradictions), and gives us a place to point people who are getting started. ("Best way to jump in? Read the book! It will show you the way.") Keeping the book scoped the the "Explanation" content goal really helps us narrow our scope and produce for effective materials.

I will try to set aside some time to open a PR against the README as you suggested, adding a first cut of a description of our thinking here and inviting community feedback on the idea of that content model. I will add you as a reviewer, however, because you have more experience with the model than I do.

[semioticrobotic]

I think that we should look to adopt this model of content type within the README of the Ospology repo. So, perhaps a PR along the lines of changing it (or perhaps adding a new .md file to link to from the README).

Here goes nothing, @alice-sowerby! 😬