Scope and Name of this Book

[rrrutledge]

The book was started with a focus on metrics. The ISPO Working Group wants to expand the scope to include everything about running InnerSource at an organization. This scope certainly includes metrics, but also includes things like Infrastructure, Governance, Tooling, etc. In all cases, we see sections in this book as a light introduction to specific topics or sets of topics that then link about to InnerSource Patterns for the deep-dive into any one particular topic.

I can see two possibilities for the new scope of the book:

1. How to Run InnerSource at an Organization (The ISPO Handbook?).
2. How to Run InnerSource at an Organization and How to Run an InnerSource Project (The Handbook of InnerSource?)

What should be the new scope? One of these two? Something else?

[rrrutledge]

I'll suggest that we start with 2) and then if things get unwieldy, we can split out How to Run an InnerSource Project as a separate book at that point.

[yuhattor]

How about "InnerSource Handbook"
It's simple (but not sure how we can compile the info as an actual handbook though)

[rrrutledge]

“InnerSource Guide”?

[jeffabailey]

Here are some ideas from the ToDo Group.

https://github.com/todogroup/ospodefinition.org#ospo-guides

How to Create an Open Source Program
Measuring Your Open Source Program
Tools for Managing Your Open Source Program

This content makes me wonder if we should follow suit and have different books for each?

My gut tells me an ISPO will be nested in an OSPO in most cases. However, I have no proof. There might be an opportunity to ask in our next state of InnerSource survey?

I like How To Create an InnerSource Program for our immediate need to more generalize the scope.

Unrelated to this topic:

Do we believe we could benefit from a content content comparison between our book and the ToDo group books? The end goal being alignment on statements and potential improvement contributions to all of the above at minimum.

[rrrutledge]

Managing an InnerSource Program

[rrrutledge]

@yuhattor and @jeffabailey chime in on this suggestion ☝️❓ It came up in the ISPO working group Trusted Committers meeting.

[jeffabailey]

@yuhattor and @jeffabailey chime in on this suggestion ☝️❓ It came up in the ISPO working group Trusted Committers meeting.

We talked about using How to Create an InnerSource Program , to align with How to Create an Open Source Program, but then I think @rrrutledge and @dellagustin preferred Managing an InnerSource Program since managing implies creating AND maintaining an ISPO.

[spier]

What ground do the other books that we have already cover? (However those might be dated and not as as easy to update)

How do we handle the overlap between the existing books and this new one that you are discussing?

My gut reaction was that I like (1) better, as it seems like that is the type of content that we have the least of so far. Also it would suite the ISC well to have a book with ISPO in the title :) might be good for marketing the book too.

[JustinGOSSES]

Liking “How To Create an InnerSource Program” as it implies a scope probably larger than a single repo/project but could be at either enterprise level or something smaller like division or business unit.

I like the idea of people reading it and saying “that applies to me”. I worry ISPO is relatively poorly know term and even more rarely reflecting an actual team boundary, so there’s more risks using it in title. Definitely something to include in an introduction blurb though.