[Pattern Draft] InnerSource and Collaboration in Public Administrations #804

dicortazar · 2025-03-26T09:53:10Z

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

…ding Status.

spier · 2025-03-26T19:09:46Z

@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 · 2025-03-26T19:10:51Z

patterns/1-initial/public-administration-and-suppliers.md

+
+Key elements of the proposed InnerSource approach include:
+
+* Shared Repositories: Establishing a central repository for code, documentation, and other artifacts.


Unified Source Code Inventory

spier · 2025-03-26T19:11:44Z

patterns/1-initial/public-administration-and-suppliers.md

+* Incentives: Providing incentives to motivate developers to contribute to shared projects.
+* Clear Roles and Responsibilities: Defining roles and responsibilities for different stakeholders,
+such as project owners, developers, and reviewers.
+* Overcoming Legal and Organizational Hurdles: Addressing legal and organizational challenges, such


InnerSource License

spier · 2025-03-26T20:12:58Z

patterns/1-initial/public-administration-and-suppliers.md

+Key elements of the proposed InnerSource approach include:
+
+* Shared Repositories: Establishing a central repository for code, documentation, and other artifacts.
+* Collaborative Development: Encouraging collaboration between teams and suppliers.


How do you do that?

spier · 2025-03-26T20:15:28Z

patterns/1-initial/public-administration-and-suppliers.md

+
+* Shared Repositories: Establishing a central repository for code, documentation, and other artifacts.
+* Collaborative Development: Encouraging collaboration between teams and suppliers.
+* Transparent Processes: Implementing transparent processes for code review, testing, and deployment.


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 · 2025-03-26T20:15:35Z

patterns/1-initial/public-administration-and-suppliers.md

+* Shared Repositories: Establishing a central repository for code, documentation, and other artifacts.
+* Collaborative Development: Encouraging collaboration between teams and suppliers.
+* Transparent Processes: Implementing transparent processes for code review, testing, and deployment.
+* Incentives: Providing incentives to motivate developers to contribute to shared projects.


How do you do that?

spier · 2025-03-26T20:17:25Z

patterns/1-initial/public-administration-and-suppliers.md

+* Clear Roles and Responsibilities: Defining roles and responsibilities for different stakeholders,
+such as project owners, developers, and reviewers.


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?

Product Owner is Agile specific, depending on the process the teams use there are different roles. If you have teams using different processes you end up with different roles.

From an InnerSource perspective: Would the TrustedCommitter Pattern be something to link to here? Also we have the learning path that we could reference - it provides information targeted at TrustedCommitters, Contributors, Product People... just thinking out loud.

dicortazar · 2025-03-28T09:21:27Z

@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!

MaineC · 2025-04-10T14:19:23Z

patterns/1-initial/public-administration-and-suppliers.md

@@ -0,0 +1,78 @@
+## Title
+
+InnerSource and Collaboration in Public Administrations


Taking a step back: You submitting a pattern about InnerSource in public admin to me means InnerSource adoption in the public sector to the degree where there's enough experience to talk about it (semi)publicly - YEAH! That is awesome to read here! Especially with the challenges in the public compared to the private sector.

MaineC · 2025-04-10T14:20:49Z

patterns/1-initial/public-administration-and-suppliers.md

+The problem to solve is how to foster a more collaborative and efficient development ecosystem
+within the public administration and between this and its suppliers.
+The aim is to promote code sharing, reuse, and knowledge transfer to reduce costs, improve quality,
+and accelerate development.


Reading this before having read the remainder of the pattern I wonder, if we'll learn about just internal adjustments or also get to look at mandates that come through legislation...

MaineC · 2025-04-10T14:21:41Z

patterns/1-initial/public-administration-and-suppliers.md

+
+Public administrations are typically slow making decisions, but when a decision is made, this stays
+for longer time. Decisions are conservative as they have to serve citizens, and they usually base most
+of the development effort in outsourced partners.


Would it make sense to add the reason for the preference for outsourcing here?

MaineC · 2025-04-10T14:24:17Z

patterns/1-initial/public-administration-and-suppliers.md

+The proposed context is the relationship between a public administration, all its suppliers, and the
+process to build a trusted collaboration environment. There are not official channels to accelerate
+certain developments while the backlog keeps growing over time, even when suppliers are willing to
+advance in some of those tasks.


With a growing number of states putting mandates for "public money, public code" in place, I wonder if this pattern idea might lead us to a better understanding of
a) how InnerSource can help foster collaboration if development happens behind closed doors, but at least the resulting product is shipped under an OSI approved license so the public admin has full control over it
b) a better understanding of when to go for OSS instead
c) a path to increase even public OSS collaboration capabilities of suppliers

MaineC · 2025-04-10T14:26:02Z

patterns/1-initial/public-administration-and-suppliers.md

+
+## Solutions
+
+To address these challenges, the organization may explore the adoption of InnerSource practices.


"the organization" is fairly vague here: Do you mean "people employed by the public admin to develop systems", "people working for a public admin supplier", "both, public admin employees and supplier employees" or "employees of different suppliers"?

MaineC · 2025-04-10T14:27:12Z

patterns/1-initial/public-administration-and-suppliers.md

+
+Key elements of the proposed InnerSource approach include:
+
+* Shared Repositories: Establishing a central repository for code, documentation, and other artifacts.


https://opencode.de/de ... do you mean something like that? (That's the German version, are there equivalents in other countries?)

MaineC · 2025-04-10T14:31:20Z

patterns/1-initial/public-administration-and-suppliers.md

+* Clear Roles and Responsibilities: Defining roles and responsibilities for different stakeholders,
+such as project owners, developers, and reviewers.
+* Overcoming Legal and Organizational Hurdles: Addressing legal and organizational challenges, such
+as intellectual property rights and procurement regulations.


Procurement regulation likely warrants a pattern of it's own - as in: "Which kind of regulation fosters InnerSource/Open Source, which stops it?" - there could even be best practices on how to phrase calls for bids.

MaineC · 2025-04-10T14:33:28Z

patterns/1-initial/public-administration-and-suppliers.md

+
+## Resulting Context
+
+* Suppliers would start working in a more collaborative way as the legal framework has evolved and allow


If I'm not mistaken there's two key pieces to this pattern that are specific to public vs. private players:

Legal procurement challenges when doing InnerSource/Open Source in the public sector.

Potentially highlighting economic incentives for InnerSource/ Open Source in the public sector.

I wonder if we would need localized versions of this pattern as they may differ going from country to country.

Create public_administration_and_suppliers Initial pattern

43be80a

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

dicortazar requested review from lenucksi, NewMexicoKid, cewilliams, spier, robtuley and yuhattor as code owners March 26, 2025 09:53

Rename file

673be8f

spier added 1-initial Donuts, Early pattern ideas, ... (Please see our contribution handbook for details) 📖 Type - Content Work Working on contents is the main focus of this issue / PR labels Mar 26, 2025

spier added 3 commits March 26, 2025 13:27

Fix typo

a8b04ca

Fix markdownlint issues

0a9779c

Don't fail on PRs that don't contain links

a5103ac

spier added this to Patterns Work Mar 26, 2025

spier changed the title ~~Create public_administration_and_suppliers Initial pattern~~ [Pattern Draft] InnerSource and Collaboration in Public Administrations Mar 26, 2025

Breaking up Resulting Context into bullets. Formatting of authors. Ad…

aa27b65

…ding Status.

spier reviewed Mar 26, 2025

View reviewed changes

spier moved this to Waiting for Author in Patterns Work Mar 26, 2025

github-actions bot mentioned this pull request Apr 1, 2025

Monthly Metrics: New Issues + New Pull Requests 2025-03-01..2025-03-31 #809

Closed

MaineC reviewed Apr 10, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Pattern Draft] InnerSource and Collaboration in Public Administrations #804

[Pattern Draft] InnerSource and Collaboration in Public Administrations #804

dicortazar commented Mar 26, 2025

spier commented Mar 26, 2025

spier left a comment

spier Mar 26, 2025

spier Mar 26, 2025

spier Mar 26, 2025

spier Mar 26, 2025

spier Mar 26, 2025

spier Mar 26, 2025

MaineC Apr 10, 2025

dicortazar commented Mar 28, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025

MaineC Apr 10, 2025


		Key elements of the proposed InnerSource approach include:

		* Shared Repositories: Establishing a central repository for code, documentation, and other artifacts.

		* Clear Roles and Responsibilities: Defining roles and responsibilities for different stakeholders,
		such as project owners, developers, and reviewers.

		@@ -0,0 +1,78 @@
		## Title

		InnerSource and Collaboration in Public Administrations


		## Solutions

		To address these challenges, the organization may explore the adoption of InnerSource practices.


		## Resulting Context

		* Suppliers would start working in a more collaborative way as the legal framework has evolved and allow

[Pattern Draft] InnerSource and Collaboration in Public Administrations #804

Are you sure you want to change the base?

[Pattern Draft] InnerSource and Collaboration in Public Administrations #804

Conversation

dicortazar commented Mar 26, 2025

spier commented Mar 26, 2025

spier left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

dicortazar commented Mar 28, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment