Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/workflows/link-checker-prs.yml
Original file line number Diff line number Diff line change
Expand Up @@ -41,6 +41,7 @@ jobs:
with:
args: --verbose --no-progress --cache --max-cache-age 1d $MARKDOWN_FILES
fail: true
failIfEmpty: false
jobSummary: true
env:
GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}
78 changes: 78 additions & 0 deletions patterns/1-initial/public-administration-and-suppliers.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
## Title

InnerSource and Collaboration in Public Administrations
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Problem

A public administration organization is struggling with siloed development practices and
inefficient resource utilization. Many projects are developed independently, leading to
redundant efforts, inconsistent quality, and difficulties in maintaining and upgrading systems.

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...


## Context

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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


## Forces

* Siloed Development: Teams often work in isolation, unaware of each other's work or potential
synergies. This leads to redundant efforts, inconsistent code quality, and difficulties in maintaining
and upgrading systems.
* Lack of Standardization: There's a lack of standardized development practices, tools, and
methodologies across teams. This results in inconsistent code quality, increased maintenance costs,
and difficulties in onboarding new team members.
* Limited Code Sharing: Code sharing is often restricted due to concerns about intellectual property,
security, and organizational silos. This limits the potential for collaboration and knowledge sharing.
* Bureaucratic Hurdles: Complex approval processes, bureaucratic red tape, and rigid organizational
structures hinder innovation and slow down development cycles.
* Insufficient Incentives: There's a lack of incentives to encourage developers to contribute to shared
projects and collaborate with others.
* Cultural Resistance to Change: Some individuals may resist changes to traditional development practices
and may be hesitant to adopt new approaches like InnerSource.

## Solutions

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"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"?


Key elements of the proposed InnerSource approach include:

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

* Collaborative Development: Encouraging collaboration between teams and suppliers.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you do that?

* Transparent Processes: Implementing transparent processes for code review, testing, and deployment.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

* Incentives: Providing incentives to motivate developers to contribute to shared projects.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do you do that?

* Clear Roles and Responsibilities: Defining roles and responsibilities for different stakeholders,
such as project owners, developers, and reviewers.
Comment on lines +54 to +55
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

* Overcoming Legal and Organizational Hurdles: Addressing legal and organizational challenges, such
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as intellectual property rights and procurement regulations.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Resulting Context

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

them to work accordingly.
* At the same time, the centralized assets would help to have visibility on the
next steps and given the existence of a public backlog, this would allow to accelerate certain areas
of interest for the public administration and the several suppliers.

## Status

Initial

## Authors

* Eva María Iglesias, Balidea
* Pablo Paz-Trelles, Xunta de Galicia
* Jesús Rey, Altia
* Javier, Altia
* Pablo Sanxiao, OSPO Xunta de Galicia
* Daniel Izquierdo, Bitergia