Extracting InnerSource information from GitHub’s Engineering Fundamentals program

[spier]

I just read this blog post:
GitHub’s Engineering Fundamentals program: How we deliver on availability, security, and accessibility

Now wondering how this might relate to InnerSource, and will be putting some questions around that below.

[spier]

The concept of durable ownership seems relevant for InnerSource.

The article defines it as:

Durable ownership: maintains ownership of software assets and ensures communication channels are defined.

The scorecards that measure compliance for durable ownership include

For example, the service must have an executive sponsor, a team, and a communication channel on Slack as part of the requirements.

Questions:

• Are there other properties of durable ownership that GitHub could share? i.e. other than " executive sponsor, a team, and a communication channel on Slack"
• How does GitHub see the relationship between durable ownership and InnerSource?

[spier]

The article introduces the concept of scorecards, to measure progress/compliance towards the three program pillars:
Availability, Security, and Accessibility

Do these scorecards contain any properties other than "durable ownership" that may affect the successful implementation of an InnerSource mindset/workflow?

[spier]

There was a talk at the last ISC Summit about Leveraging scorecards to scale InnerSource. Possible this could be combined with the input from GitHub and turned into a pattern?

[spier]

@zkoppert @yuhattor curious to hear your perspective on these questions.

[yuhattor]

The discussion in this article seems to have quite an operational aspect regarding ownership. It is more of a contextual discussion in the "Service vs Library" pattern, and seems to be more about how to maintain a Trusted Committer in the operation of InnerSource code that is tied to the Service.

On the other hand, the scorecard discussion at the last ISC Summit was more like what is suggested in Repolinter, and I think there are many items related to collaboration.
If these stories were added to his scorecard story, it would be much more solid.

In that sense, I think this scorecard is quite operations-oriented and not directly related to the InnerSource scorecard. Would love some input from @zkoppert on this.

[yuhattor]

I think it's a good idea to connect this story, because in the DevSecOps world, shift-left is being practiced and how important it is to ensure high quality code and DevOps teaming including such operations is important, but the actual distance between co-creation and security, etc. is still far.

I think it would be beautiful if it could be told in the same context.

[zkoppert]

Scorecards/Durable Ownership can be helpful for InnerSource in the sense that it helps maintainers improve the project quality and ownership and sets the tone for organizational standards. For example if every InnerSource project needs a list of Maintainers, a README file, and security scans turned on and you make a scorecard for that, it helps to ensure that standard across the organization. I'd be willing to try and create a pattern around this.

[mcobby]

"Durable ownership" is a technique I used in the past where a company needs accountability at all stages of the lifecycle. I established a small central team that would run monthly reports on IS project compliance. It was very lightweight and we checked that the repo owners were still in the organisation, we checked for minimum levels of meta data files (READ.me), CODEOWNERS, Code of Conduct. We didn't publish it as a score card but we used the data to find projects that might be getting into trouble and go talk to them to see what help they needed. One use of the scorecard I didn't get to was for users to decide if they were going to use a project or not. Did it give them confidence that they were going to be supported.

[spier]

Thanks for sharing this story @mcobby!

It seems that these checks for "is this project still maintained" would typically be implemented at a program level (by some central team). And I agree that besides checking this for compliance (to prevent getting into trouble), it could also boost the confidence of potential adopters and contributors to the project.

Really seems like a basic hygiene check. Like the InnerSource Portal probably one of the patterns that most orgs should implement. In a way these durable ownership checks should even be implemented if the org does not actively practice InnerSource, shouldn't they? When writing a pattern about this we might check if others have spoken about this approach publicly (even outside of the InnerSource context).

Do you know where the term "durable ownership" stems from? Did you use that exact term at that other org?

Also any idea if that org that you mentioned still uses this approach and might be willing to contribute to a pattern about this?