Add InnerSource principles to list of draft patterns

[MaineC]

Several months ago there was a discussion at the InnerSource commons to come up with an InnerSource manifesto. We never came to a final version of that document. However an early version of it was used over at Europace to come up with a list of common InnerSource principles.

Maybe this pattern can serve as a starting point for re-starting the discussion on a common InnerSource manifesto.

[spier]

Hi @MaineC. This is an interesting idea.

It sounds like you want to use this new pattern about the principles to derive a manifesto from there?
Would it help to start by creating a shared understanding of what these terms mean, so that we can talk about the same thing? Can you explain the conceptual relationships between manifesto and principles?

My mind went to the Agile manifesto and principles straight away. But I am not 100% sure what the relationship between those two is either.

Also, is there a draft version of the manifesto available that we can already share here? Or do you think it would just distract the conversation about the principles?

[spier]

FYI I fixed the things that the markdown linter was complaining about, so that we can now focus on the content of the pattern. :)

[MaineC]

It sounds like you want to use this new pattern about the principles to derive a manifesto from there?

That would be the ideal outcome. If we can factor the actual principles/manifesto out of this pattern, move them to a separate document and only reference them in the pattern, that would be nice.

At the very minimum I wanted to share what worked in our case - maybe others find it helpful. Maybe others have valuable feedback that helps make the current version better.

Would it help to start by creating a shared understanding of what these terms mean, so that we can talk about the same thing? > Can you explain the conceptual relationships between manifesto and principles?

So years ago we discussed creating an InnerSource manifesto, much like there is an agile manifesto. I cannot speak for others, for me the idea was to capture in maybe a handful of sentences what the essence of InnerSource is about. Sort of like a compass that practitioners can use on a daily basis to guide their decisions: https://en.wikipedia.org/wiki/Manifesto

In order to avoid confusion between any potential version here at InnerSource Commons and what our internal teams use I chose to use a different term. That's why right now they are called principles.

My mind went to the Agile manifesto and principles straight away. But I am not 100% sure what the relationship between those
two is either.

After a very brief look the principles there seem to extend the manifesto.

Also, is there a draft version of the manifesto available that we can already share here? Or do you think it would just distract the
conversation about the principles?

The discussion I remember was fairly lengthy. Some of the people heavily involved back then have moved on. So it might be a good idea to start the discussion from a clean starting point, maybe sharing the pattern pull request here with the wider community so others have a chance to provide their input.

[spier]

I left rather extensive comments of various sorts. From typos, to grammar, to formatting, to content suggestions. Hope you find them useful.

On a general level, I find this pattern very useful. It is specific enough to be applicable. And also not too prescriptive, so that readers can adapt it to their own context.

It seems like this pattern should be applied pretty early on in the InnerSource journey of a company, as otherwise if the company doesn't know what problems they are solving for, how would they choose what approaches to invest in?

[spier]

Is it really that these are perspectives that they should understand, or are you rather advising them to follow these two steps as part of your solution? I think it is the latter :)

[MaineC]

I do mean understand two perspectives. However reading this after a break of a few weeks I see how the phrasing was unclear. What I mean is that those who should adopt InnerSource need to understand these two perspectives - not the ones originally involved with rolling out InnerSource.

[spier]

The current Solution section mostly sounds more like you are talking to "the ones rolling out InnerSource" actually.
However you might have changed your mind there, midway in writing, as it doesn't seem 100% consistent. 😄

Let me try to make some inline suggestions, and see if those changes increase clarity.

I think that the Solution section should indeed be written for the "the ones rolling out InnerSource", because this pattern would be used by that group, in order to provide more clarity to the rest of the org (the ones that they want to adopt InnerSource).

[MaineC]

@spier I went through your comments - a lot of those made sense, thank you for them. Also committed the changes you suggested. As to your question:

It seems like this pattern should be applied pretty early on in the InnerSource journey of a company, as otherwise if the
company doesn't know what problems they are solving for, how would they choose what approaches to invest in?

Yes - though in a way people will refer back to this pattern repeatedly in my experience. With every step that the InnerSource initiative grows towards new teams or departments the pattern will be helpful again. I do agree with you though, that this should be applied very early on in the process.

[spier]

Other notes (mostly for myself) of changes that we can make at the end of this PR:

• add specific suggestions from the Patlet into the Solution section (e.g. "get published widely")
• change pattern file name to match the title (i.e. explicit-innersource-principles.md
• add pattern to the list in README.md

[spier]

Hi @MaineC, I left some more inline comments in this PR:
https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/325/files

If you review these, then I think that this PR is ready to merge.
With the PR merged to the mainline it will also become easier to share this pattern with other interested readers. Therefore I would suggest to do this fairly quickly now :)

[spier]

Also don't worry about the failing checks. I have already fixed those in main, so once we merge the checks will pass.

[spier]

I am opting to merge the pattern even though the are still failing linter checks. It will be easier for me to fix those on a separate PR after this.