Break down and estimate related project by ZenDiS "Badges"

[0xf1e]

Good evening!

I'm at Open Source Summit atm, and ZenDiS has presented their following project: https://badges.opencode.de/en/

This is limited to their OpenCode repository, but otherwise seems extremely close to what this project is trying to achieve.
I believe that we should take a close look at ZenDiS badges before continuing with this project in its current state.
Their code is, of course, fully open source: https://gitlab.opencode.de/open-code/badgebackend

[0xf1e]

Today I've been to a talk by Gergely Csatari from Nokia who, when faced with similar problems, created an extension of the OpenSSF score card.

https://openssfcdeu2025.sched.com/event/25dHf/beyond-the-scorecard-managing-open-source-operability-risk-in-telecoms-gergely-csatari-nokia?iframe=yes&w=100%&sidebar=yes&bg=no

I haven't been able to find his wrapper around the scorecard in Nokia's open source repo, but I can reach out to him and ask for more details when needed.

The overall impression that I've been getting at the OpenSSF Community Days is that a lot of people are currently working on OSS repo analysis, because of the requirements set by the Cyber Resilience Act.

[janhalen]

@0xf1e: I would love a set of estimations for what would need to be done to port the Badges code to support github. And estimates for trying it out on a couple of os2repos.

Interresting if we could get acces to the Nokia code too... is there something i could do to move it along?

[janhalen]

@0xf1e : would Jesper be interrested in participating here? Feel free to point him in this direction.

[0xf1e]

Hi! I've been working on-site all week, so I've unfortunately haven't been able to find as much time for this project as I'd like to, but the past days, I've been playing around a little with a self-hosted copy of the badges-api. I've found it fairly easy to set up, thanks to the provided helm chart.

I don't have an answer yet to how challenging it would be to port the api to github, figuring that out will be the next step.
(although my first step in this regard would be seeking contact with the zendis people about whether they are aware of any porting efforts)

For the time being, I'd like to share the API outputs of my test runs with two arbitrarily chosen gitlab repos, those being https://gitlab.com/dwt1/dotfiles and https://gitlab.com/corectrl/corectrl.

dotfiles_report.json
corectrl_report.json

And because I don't love reading json, I've also fed these API outputs to an LLM, which I prompted to create human-readable summaries of the results:

For dotfiles repo:

Project Badge Analysis Summary

This analysis evaluated the repository https://gitlab.com/dwt1/dotfiles across four badge categories. Here's a human-readable summary of the results:

🏆 Achieved Badges

✅ Active Maintenance Badge (Bronze) - GRANTED

• The project meets minimum requirements for being actively maintained
• 69 commits in the last 6 months (exceeds requirement of 5)
• No external issues to respond to in the last 3 months

❌ Failed Badge Requirements

Security Badge (Bronze/Silver) - NOT GRANTED

Issues:

• Missing SECURITY.md file in the root directory
• No code review process (no merge requests in last 6 months)
• No signed tags created in the last 6 months

Strengths:

• ✅ Main branch is properly protected with correct permissions
• ✅ Force push is disabled on the default branch

Reuse Badge (Bronze/Silver/Gold) - NOT GRANTED

Issues:

• No packages published in the last 6 months
• No CI/CD pipelines executed
• Zero documented reuses of the project

Open Source Badge (Gold) - NOT GRANTED

Issues:

• License not approved by Zendis for openCode platform

📊 Key Project Statistics

• Activity Level: High (69 commits in 6 months)
• Contributors: 1 (single maintainer project)
• Releases: 0 in the last 6 months
• External Community: Limited (no external issues or merge requests)

🔍 Areas for Improvement

1. Security: Add a SECURITY.md file to document security policies
2. Release Management: Create regular releases/tags
3. CI/CD: Implement automated pipelines
4. Community: Encourage external contributions and code reviews
5. Documentation: Add proper licensing information
6. Distribution: Publish packages for easier reuse

The project shows strong development activity but lacks some infrastructure elements needed for higher-level badges, particularly around security documentation, release management, and community engagement.

For corectrl repo:

Project Analysis Summary for CoreCtrl

This analysis evaluated the CoreCtrl project (https://gitlab.com/corectrl/corectrl) across four badge categories. Here are the results:

🏆 Badges Earned

✅ Active Maintenance Badge - Silver Level

• The project meets requirements for reliable maintenance
• Regular releases and quick issue response times
• Active community engagement

✅ Open Source Badge - Gold Level

• Uses GPL-3.0+ license which is approved for openCode
• Fully compliant with open source requirements

📊 Detailed Results

Security Assessment

Current Level: Not achieved (Bronze requirements partially met)

✅ Strengths:

• Fast issue response time (1 day average)
• Proper branch protection with force push disabled
• Correct merge/push permissions (level 40)

❌ Areas for Improvement:

• Missing SECURITY.md file in root directory
• No signed tags (0% of 5 tags created in last 6 months)
• No code review process detected (no merge requests in last 6 months)

Maintenance Status

Current Level: Silver Badge Earned

✅ Strengths:

• Very active development (36 commits in last 6 months)
• Excellent issue response time (1 day)
• Regular releases (5 releases in last 6 months)

❌ Limiting Factor for Gold:

• Single contributor dependency (Contributor Absence Factor = 1)
• Project relies heavily on one main contributor

Reusability

Current Level: Not achieved

✅ Strengths:

• Packages available (5 releases with attached files)

❌ Areas for Improvement:

• No CI/CD pipelines running
• Zero documented reuse by other projects
• Missing automated testing/quality assurance

🎯 Recommendations

1. For Security Badge:

   • Add a SECURITY.md file to document security policies
   • Implement tag signing for releases
   • Set up code review processes

2. For Maintenance Resilience:

   • Encourage additional contributors to reduce single-person dependency
   • Consider mentoring new contributors

3. For Reusability:

   • Set up CI/CD pipelines for automated testing
   • Improve documentation to encourage adoption
   • Promote the project to increase usage

The project shows strong maintenance practices and proper open source licensing, but could benefit from improved security practices and broader contributor engagement.

[0xf1e]

So, it appears that any gitlab related code is fully abstracted behind the gitclient interface: https://gitlab.opencode.de/open-code/badgebackend/badge-api/-/tree/main/pkg/gitclient

To make Zendis Badges work with Github, what we need to do is write a github-specific implementation of gitclient. It seems that no, or only little other code adjustments are needed. For some functions I imagine this being quite trivial (getting repos, issues, etc), while for others, the APIs might not translate 1:1 (for example when it comes to packages or CI pipelines)

[0xf1e]

Also, since you're describing a workflow similar to the ZenDiS Badges one as "serverless" in your README.md, I should mention that the way the program works at the moment, is by hosting a service that provides an API.
They have a deployment helm chart here: https://gitlab.opencode.de/open-code/badgebackend/badge-api-helm-chart

Edit: The API runs statelessly however, so you could probably still convert the helm deployment into a Github Action.

[0xf1e]

Hello!

I just wanted to quickly update you to share that the ZenDiS Bages project now has a "Badge Report" feature, which visualizes the results of the Badge API in a more appealing way: https://badges.opencode.de/de/?repositoryUrl=https%3A%2F%2Fgitlab.opencode.de%2Fopen-code%2Fbadgebackend%2Fbadge-api