[Pattern Draft] InnerSource and Collaboration in Public Administrations

[dicortazar]

Pattern on the relationship between a public administration and its suppliers in an InnerSource context

[spier]

@dicortazar thank you for sharing this story of how InnerSource can help in Public Administration.

Some observations from a first read:

The pattern is about a specific "industry" (public administration), which is an approach that we have not used in other patterns so far. How is that industry different from other industries? Do they have challenges that other orgs don't have? Or could we express these challenges in ways that would be applicable to other industries as well.

Currently the pattern is rather broad. Like a "story of how to introduce InnerSource in Public Administration". Our other patterns try to describe one problem, and one solution. i.e. they are more focused on one thing only.

One idea:

• Could we try to take the solutions that you are proposing, and link them to other patterns that we already have?
• For the problems/solutions that we cannot find patterns for, we could try to explain the solution in a bit more detail (1-3 paragraphs). If we find those ideas convincing, then we could try to write a dedicated patterns for these.

I will go through your text and try to add links to other existing patterns, to see if that helps.

Happy to explore any other ideas of how we could turn these experiences in the Public Administration domain into patterns.

[spier]

I left some specific pointers to existing patterns inline.

[spier]

Unified Source Code Inventory

[spier]

InnerSource License

[spier]

How do you do that?

[spier]

What do you mean by "transparent" in this context?

I think we would benefit form a pattern about doing amazing code reviews. i.e. code reviews that help the contributors as much as possible

However I assume that you have more basic requirements in mind here?

[spier]

How do you do that?

[spier]

At least for teams working in "agile ways", roles like product owner and developer are typically rather well defined. Not sure about reviewer.

Why is it that these roles are not defined in the IT of Public Administration?

[dicortazar]

@spier, I'll answer inline

@dicortazar thank you for sharing this story of how InnerSource can help in Public Administration.

Some observations from a first read:

The pattern is about a specific "industry" (public administration), which is an approach that we have not used in other patterns so far. How is that industry different from other industries? Do they have challenges that other orgs don't have? Or could we express these challenges in ways that would be applicable to other industries as well.

This was my very first question. But it is true that this is a very specific context. However, I didn't see this as valuable to have all this information in the context, and there are specific challenges that a public administration is facing. Although it is true we can generalize those, I still think there are some specific issues per industry that I am still not sure how to reflect them in patterns.

We can probably summarize (from what I've learned all these years) those as:

• Very specific way of contracting third parties: there is a specific process on how procurement is done, and this is difficult to change within the organization as this depends on those making the laws. Everyone is constraint by this, the public administration and the suppliers.
• There is an existing relationship with suppliers that I think it is harder to break if compared to the private sector.
• Comfort zone and organizational changes: it is harder than in the private sector to force them as public servants have a secured position, processes are typically slower and champions find a lot of walls to move forward.
• Political direction: this might be closer to how politics work in a big corporation, but depending on the unit, there might be a political responsible at the top of the hierarchy and this may change those directions.
• Even when there is willingness, it is hard to find the way to work given the rigid structure.

And said all of this, there are public administrations that are able to deal with all of this.

Currently the pattern is rather broad. Like a "story of how to introduce InnerSource in Public Administration". Our other patterns try to describe one problem, and one solution. i.e. they are more focused on one thing only.

I agree with your comment.

One idea:

• Could we try to take the solutions that you are proposing, and link them to other patterns that we already have?

When I wrote the list of challenges and potential solutions, that's what I thought as well. +1 :).

• For the problems/solutions that we cannot find patterns for, we could try to explain the solution in a bit more detail (1-3 paragraphs). If we find those ideas convincing, then we could try to write a dedicated patterns for these.

I will go through your text and try to add links to other existing patterns, to see if that helps.

Happy to explore any other ideas of how we could turn these experiences in the Public Administration domain into patterns.

Thank you!