Pattern Idea: Hive mind

[mishari]

This pattern proposal illustrates exactly what I'm trying to describe.

Often in corporations, there's a strong need to release a finished idea into the open. But here in the InnerSource Commons, even a vague intuition can be expressed, with others in the community contributing to help make it whole, or discrediting it.

When implementing InnerSource or even open source, one should be encouraged to open up early on to elicit feedback from other participants in the community, treating the community as a "hive mind".

Based on my talks with others in the community, this seems to be a novel idea, so I think it can be formalized into a pattern.

[spier]

What would be examples of "open up early" in the software development process?

On a single-repo-level, here some things I can think of (but not sure if that is what you are after):

• creating an issue on a repo, describing an idea for how to fix a problem or implement a feature (without a strong attachment to an exact implementation, and also without a commitment to actually do it i.e. just exploring what is possible)
• opening a PR with the bare minimum to be needed to explain an idea (sometimes it is easier to show what you mean in code than in text (i.e. the PR has unfinished tests, missing docs, etc)

[obuzek]

This is especially fascinating to me because we've used the same term - "hive mind" - to describe a different kind of behavior.

We've been using "hive mind" to express what a repository looks like that has careful quality standards put in place, such that the code that collectively gets written looks like it's been written by a hive mind.

[spier]

We've been using "hive mind" to express what a repository looks like that has careful quality standards put in place, such that the code that collectively gets written looks like it's been written by a hive mind.

This sounds interesting @obuzek. Are there any particular practices that are impactful in trying to achieve that "code looks like it was built by a hive mind" state? I am also wondering what the dark label of this approach is i.e. when do the quality standards become so rigid/strict that new outside contributors are overwhelmed by the amount of checks and rules, making it harder to make InnerSource contributions.

Would you like to open a new GitHub issue for this, to try to explore that in a pattern of its own?

[mishari]

@spier I think all of the above, but also have a mailing list where one can discuss ideas. Several people I've spoken to in the InnerSource Slack Donut who were involved in bringing InnerSource to their organization seemed excited when I suggested to them that instead of looking for ways forward by themselves, they should just ask their respective communities for suggestions on how to move forward.

It seems in many organizations the culture is to solve a problem by yourself, or in a team, but not so much to do so in the open, bringing in participants and interested parties from far and wide.

[spier]

I see. So the pattern might be a way to motivate people in an org to "ask for help" in a way. And yes, I can imagine that this is a behavior that might need training and culture change, if it isn't there naturally.