Alexandre Dulaunoy - adulau - Home Page

How mature is this repository? My long quest for open-source software metrics

Sat, 15 Aug 2026 00:00:00 +0200

How mature is this repository? My long quest for open-source software metrics

For years, I have been looking for a reasonable answer to a deceptively simple question:

When I discover an open-source software project for the first time, how can I estimate whether it is mature, healthy and usable?

Usually the first encounter is a repository on GitHub, GitLab, Codeberg or another forge. And usually we start looking at the obvious things.

How many stars does it have? When was the last commit? How many contributors are there? Are there recent releases? Are issues being answered?

Those indicators are useful. But none of them answers the question.

A project with 20,000 GitHub stars can be abandoned. A project with 20 stars can be a boring but essential component maintained for fifteen years. A project with hundreds of commits per week may simply have a lot of automated dependency updates. A project with very few commits might actually be finished and extremely stable.

Even GitHub describes stars primarily as a way to bookmark repositories and, at best, as an approximate indication of interest.¹

So the problem is not the absence of metrics.

The problem is that there are far too many metrics, they measure different things, and combining them into something meaningful is surprisingly difficult.

Metrics everywhere

There has been a lot of excellent work in this area.

CHAOSS develops metrics and metric models specifically for understanding open-source community health and sustainability.² Its catalogue contains metrics ranging from release frequency and time to first response to Contributor Absence Factor, organizational diversity, project burnout, documentation accessibility and licensing.

The Apereo OSS Health and Sustainability Rubric takes another approach and groups more than forty criteria into broad areas covering Community, Governance, Development, Support and Security/Privacy.³

The Apache Software Foundation has its own Project Maturity Model, covering code, licensing, releases, quality, community, consensus building, independence and governance.⁴

For security there is the OpenSSF Scorecard, which automatically evaluates a repository against security-related heuristics.⁵ OpenSSF also maintains its Best Practices Badge programme, which combines automatically verifiable information with information supplied by maintainers.⁶

There is even an OpenSSF Criticality Score, which tries to estimate how important an open-source project is using signals such as project age, contributor count, organizations involved, commit frequency, releases, issue activity and dependency information.⁷

Academic research reaches the same conclusion from another direction: OSS health is inherently multidimensional. One literature review identified more than one hundred characteristics distributed over fifteen themes.⁸

So we have metrics.

Lots of metrics.

What we don’t really have is a simple answer when encountering an unknown repository for the first time.

The TRL idea

For many years, in various discussions around open-source projects, we came back to the idea of reusing Technology Readiness Levels, or TRLs.

TRL is the familiar scale from 1 to 9, first developed in the NASA context and later reused by ESA, the European Commission and many research programmes.⁹¹⁰

Anyone involved in European research projects has probably encountered TRLs in one proposal or another. Horizon Europe continues to use the concept to describe the maturity expected from research and innovation activities.¹¹

Of course, applying traditional TRL directly to open-source software doesn’t really work.

A Git repository cannot tell us whether a technology has been demonstrated in an operational environment. GitHub cannot reliably tell us how many hospitals, companies, CERTs, universities or spacecraft are actually using a piece of software.

But I still like one property of TRL:

everybody understands a progression from 1 to 9.

So perhaps we could reuse the idea of TRL without pretending that repository metrics are equivalent to NASA’s technology assessment.

This became OSSTRL — Open Source Software Technology Readiness Level.¹²

OSSTRL

OSSTRL is an experiment.

Its goal is to estimate an open-source software readiness level from 1 to 9 using evidence that can be automatically collected from a GitHub repository.

The current prototype borrows heavily from the structure of the Apereo OSS Health and Sustainability Rubric and groups evidence into:

Community;
Governance;
Development;
Support;
Security and Privacy.

It collects things such as repository age, contributors, activity, releases, documentation, governance files, CI, tests, security policies and responsiveness.

Those individual observations produce a weighted evidence score, which is mapped to an OSSTRL level.

But there are two important twists.

First, coverage/confidence is reported separately from the score. If something cannot be measured from GitHub, it should not silently become a zero.

Second, there are readiness gates. A repository cannot reach a high level merely by collecting enough cheap points. For example, higher OSSTRL levels progressively expect evidence such as active development, releases, several contributors, governance, a security policy, CI and tests.¹²

This is deliberately imperfect.

And that’s actually part of the experiment.

What can we measure?

While working on OSSTRL, I started compiling the metrics that could be useful when evaluating an open-source project.

The following catalogue is intentionally broad. Some metrics overlap. Some are good indicators, some are terrible indicators when used alone, and some are almost impossible to automate correctly.

I use three rough classes:

[A] Automatable — normally obtainable from a forge, repository, package ecosystem or automated analysis.
[P] Partially automatable — useful evidence can be collected automatically, but interpretation is required.
[H] Human/external evidence — usually requires maintainers, users or external verification.

These categories are intentionally approximate. Even an apparently simple automated metric can become ambiguous once different development models, mirrors, bots or external infrastructure enter the picture.

Repository identity and discoverability

[A] Repository age — time since repository creation.
[A] Public accessibility — whether the authoritative source repository is publicly accessible.
[A] Archived status — whether the repository is explicitly archived.
[A] README presence.
[P] README completeness.
[A] Project description present.
[A] Homepage/project website configured.
[A] Repository topics/tags.
[A] Documentation directory present.
[P] Documentation discoverability.
[P] Documentation usability.
[P] Documentation accessibility.
[A] Installation instructions present.
[A] Developer setup instructions present.
[A] Examples/tutorials present.
[A] API documentation artifacts.
[A] CHANGELOG/history present.
[A] CONTRIBUTING file present.
[A] Code of Conduct present.
[A] Issue templates present.
[A] Pull-request templates present.
[A] SECURITY policy present.
[A] Governance documentation present.
[A] Maintainer list present.
[A] CODEOWNERS present.
[A] Roadmap present.
[A] Funding metadata present.

GitHub itself exposes a community-profile API based on several of these repository artefacts, such as the presence of a README, licence, Code of Conduct and contribution documentation.¹³

These metrics are useful because they are easy to collect. They are also dangerous because the existence of GOVERNANCE.md does not prove that governance works, just as the existence of SECURITY.md does not prove that vulnerabilities are handled properly.

Popularity, visibility and adoption

This is the category where misleading metrics are especially common.

[A] Star count.
[A] Star growth/velocity.
[A] Watchers/subscribers.
[A] Fork count.
[P] Active forks rather than merely created forks.
[A] Repository clones where statistics are available.
[A] Unique cloners.
[A] Repository page views.
[A] Unique visitors.
[A] Package downloads.
[A] Number of distinct package versions downloaded.
[A] Container image pulls.
[A] Number of downstream dependencies/dependents.
[A] Reverse dependency count.
[P] Inclusion in operating-system distributions.
[P] Number of integration projects.
[P] Number of plugins/extensions built around the project.
[H] Number of known installations.
[H] Number of production installations.
[H] Number of distinct user organisations.
[H] Number of public references/case studies.
[P] Academic citations.
[P] Conference/tutorial references.
[P] External community activity.
[P] Project popularity/recommendability.

Stars are therefore one metric among many, not a maturity level.¹

The same is true of downloads. A dependency may be downloaded millions of times because it is part of automated build systems, while another project may have a few hundred downloads but be deployed on extremely important infrastructure.

Development activity

[A] Time since last commit.
[A] Time since last push.
[A] Commits during the last 30/90/365 days.
[A] Commit frequency.
[A] Active development days per month.
[A] Number of active branches.
[A] Branch lifecycle/duration.
[A] Code churn.
[A] Lines added/removed.
[A] Burstiness of activity.
[A] Development velocity.
[A] Periods without development activity.
[P] Ratio of maintenance commits to feature development.
[P] Ratio of human to bot activity.
[A] Bot activity.
[P] Technical forks.
[P] Development activity trend — growing, stable or declining.

Absolute activity is less useful than the trend.

A project going from fifty active contributors to five tells us something very different from a project that has operated happily with five people for ten years.

Even commit counts are not straightforward. A repository can contain generated code, automated dependency-update commits, vendored source or extremely granular commits. GitHub exposes many useful repository statistics through its APIs, but interpretation remains the difficult part.¹⁴

Contributors and community sustainability

[A] Number of unique contributors.
[A] Number of non-bot contributors.
[A] Active contributors during a defined period.
[A] New contributors.
[A] Returning contributors.
[A] Occasional contributors.
[A] Inactive contributors.
[A] Contributor growth rate.
[A] Contributor retention.
[A] Contributor churn.
[A] Contribution frequency per contributor.
[A] Distribution of contributions between contributors.
[A] Contributor Absence Factor — the smallest number of contributors responsible for a given proportion of contributions.
[A] Elephant Factor — organizational concentration of contributions.
[P] Bus factor.
[A/P] Organizational diversity.
[P] Organizational influence.
[P] Contributor location diversity.
[P] Time-zone diversity.
[P] Types of contributions — code, documentation, issues, reviews, translations, community work, etc.
[P] Labor investment.
[P] Contributor recognition.
[H] Contributor satisfaction.
[H] Newcomer experience.
[H] Psychological safety.
[H] Project burnout.
[P] Mentorship activity.
[P] Job opportunities around the project.
[P] Sponsorship of contributors.

CHAOSS is particularly valuable here because it explicitly treats community health as more than commit counting.²

A repository with one thousand historical contributors may today be maintained by one exhausted person. Conversely, a highly focused library maintained by two people for twenty years may be perfectly sustainable.

The distribution and evolution of contributions often tell us more than the absolute number.

Issues and bug management

[A] Number of open issues.
[A] New issues per period.
[A] Closed issues per period.
[A] Active issues.
[A] Issue closure ratio.
[A] Median issue age.
[A] Age of oldest unresolved issue.
[A] Time to first response.
[A] Issue response time distribution.
[A] Time to close.
[A] Issue resolution duration.
[A] Defect resolution duration.
[A] Percentage of issues receiving a human response.
[A] Backlog growth rate.
[A] Stale issue ratio.
[P] Label quality/consistency.
[P] Ratio of bugs/features/questions.
[P] New contributors successfully closing issues.

Time to first response is particularly interesting because it can be measured fairly consistently and says something about whether someone arriving at the project will encounter an active community.

CHAOSS includes response and closure metrics in its starter health model alongside release frequency and contributor-concentration metrics.¹⁵

But even here context matters. A project deliberately using a mailing list instead of GitHub Issues may look completely unresponsive if we only inspect the forge.

Pull requests and code-review practices

[A] Number of change requests/pull requests.
[A] Accepted pull requests.
[A] Declined pull requests.
[A] Pull-request acceptance ratio.
[A] Pull-request closure ratio.
[A] Pull-request duration.
[A] Time to first review.
[A] Review duration.
[A] Number of review cycles.
[A] Reviews per pull request.
[A] Commits per pull request.
[A] Number of distinct reviewers.
[A] Self-merge rate.
[A] Percentage of changes reviewed by another person.
[A] Stale pull-request count.
[A] Pull-request backlog trend.
[P] Contribution attribution quality.

These metrics help distinguish “many contributors exist in Git history” from “there is still a functioning collaborative development process”.

Review practices are also relevant from a security perspective. OpenSSF Scorecard, for example, includes code review as one of its checks because independent review reduces the risk associated with direct, unreviewed changes.¹⁶

Releases

[A] Number of releases.
[A] Number of stable releases.
[A] Release frequency.
[A] Time since latest release.
[A] Releases during the last 12/24 months.
[A] Median interval between releases.
[A] Release cadence regularity/variance.
[A] Presence of prereleases.
[A] Semantic-version-like tags.
[P] Semantic Versioning compliance.
[A] Release notes present.
[A] Changelog present.
[P] Backwards-incompatible changes documented.
[P] Supported release branches.
[P] Length of support window.
[P] Security release latency.
[A] Release artifacts available.
[A] Packages generated by CI/CD.
[A] Cryptographically signed releases.
[A] Checksums supplied for releases.

Release frequency should not automatically reward projects that release every Tuesday.

A small, stable library might legitimately release once every few years. A web application exposed to an evolving ecosystem might need a much faster cadence.

Regularity and recency are useful observations, but they should not automatically become universal requirements.

Code and engineering quality

Repository metadata alone is insufficient here, but a local checkout and CI results provide many additional metrics.

[A] Lines of code.
[A] Programming-language distribution.
[A] Code-change volume.
[A] Number of tests.
[A] Automated test suite present.
[A] Unit-test coverage.
[A] Integration-test coverage.
[A] End-to-end tests present.
[A] CI configured.
[A] CI success rate.
[A] Build success rate.
[A] Build duration.
[A] Number/rate of flaky tests.
[A] Static-analysis findings.
[A] Linter warnings/errors.
[A] Type-checking coverage.
[A] Cyclomatic complexity.
[A] Maintainability index.
[A] Code duplication percentage.
[A] Function/method size distribution.
[A] Defect density.
[A] Fuzzing present.
[P] Fuzzing coverage.
[A/P] Performance benchmarks.
[A/P] Performance regression rate.
[P] Reproducible builds.

Test coverage is itself a nice example of the general problem: 90% coverage tells us something, but it certainly doesn’t mean that 90% of the bugs have disappeared.

Similarly, code complexity has very different meanings across languages and project types.

These metrics are often useful for comparisons within the same project over time, but are less reliable when ranking unrelated projects.

Dependencies and software supply chain

[A] Number of direct dependencies.
[A] Number of transitive dependencies.
[A] Dependency depth.
[A] Upstream dependency count.
[A] Outdated dependencies.
[A] Dependency age / Libyears.
[A] Pinned build dependencies.
[A] Automated dependency-update tooling.
[A] Lock files present.
[A] SBOM present.
[A] SBOM published with releases.
[A] SPDX document present.
[A] CycloneDX/SPDX validity.
[A] Build provenance present.
[P] SLSA build level.
[A/P] Reproducible build evidence.
[A] Package published through CI.
[A] Artifact signing/attestation.

The number of dependencies is not inherently good or bad. Reusing a well-maintained library is usually preferable to reimplementing it badly.

But dependency depth, outdated components and supply-chain provenance can expose risks that do not appear in ordinary source-code activity metrics.

SLSA is interesting here because it defines increasing guarantees around software build integrity and provenance.¹⁷

SPDX provides a standardized representation for software components, licences, copyrights and relationships, making some supply-chain and legal information machine readable.¹⁸

Security

Security deserves its own set of metrics, and OpenSSF Scorecard already demonstrates how much can be checked automatically.⁵

Candidate signals include:

[A] SECURITY.md present.
[P] Clear vulnerability disclosure process.
[A/P] Security contact available.
[P] Supported versions documented.
[P] Disclosure timeline documented.
[A] Security advisories published.
[A] Known unfixed vulnerabilities.
[A] Vulnerable dependencies.
[A] Vulnerability backlog.
[A/P] Mean vulnerability remediation time.
[A/P] Time from disclosure to fixed release.
[A] Dependency-update automation.
[A] Static Application Security Testing (SAST).
[A] Fuzzing.
[A] Secret scanning/security automation.
[A] Branch protection.
[A] Code review before merge.
[A] Dangerous CI workflow patterns.
[A] Workflow token permissions.
[A] Pinned build dependencies.
[A] Checked-in binary artifacts.
[A] Signed releases.
[A] SBOM publication.
[A] OpenSSF Scorecard score.
[A/P] OpenSSF Best Practices level.
[H] Independent security audit.
[H] Security-review history.
[H] Evidence of an operational CVD/PSIRT process.

The OpenSSF approach is useful precisely because it does not reduce everything to “does SECURITY.md exist?”. Its checks include code review, dangerous workflows, dependency updates, fuzzing, pinned dependencies, SAST, token permissions, signed releases and known vulnerabilities, among other signals.¹⁶

OpenSSF’s Best Practices programme provides another useful model because it mixes observable properties with declarations from maintainers.⁶

That hybrid model is probably unavoidable if we want to evaluate things such as actual vulnerability-handling practices.

Licensing and legal clarity

[A] License file present.
[A] Recognized SPDX license identifier.
[A] OSI-approved license.
[A] License coverage across source files.
[A/P] REUSE specification compliance.
[A] Copyright statements.
[P] Copyright ownership clarity.
[A/P] Dependency-license compatibility.
[A] SPDX document available.
[P] Contributor License Agreement process.
[P] Developer Certificate of Origin/sign-off process.
[P] Third-party code attribution.
[P] NOTICE/attribution completeness.

A top-level LICENSE file is valuable evidence, but it is not sufficient to establish the legal status of every file and dependency.

The REUSE specification is particularly interesting for automation because it aims to make copyright and licensing information unambiguous and machine readable on a per-file basis.¹⁹

SPDX provides another important building block by defining standardized identifiers and document formats for communicating software licensing and component information.¹⁸

Governance

This is where repository automation starts becoming much less reliable.

[A] GOVERNANCE document exists.
[A] Maintainers documented.
[A] CODEOWNERS documented.
[P] Decision-making process documented.
[P] Contributor-to-maintainer promotion process.
[P] Voting/consensus rules.
[P] Conflict-resolution process.
[P] Public decision records.
[P] Communication transparency.
[P] Roadmap publication.
[P] Roadmap freshness.
[P] Leadership diversity.
[P] Board/council diversity.
[P] Organizational concentration of decision power.
[P] Organizational concentration of commits.
[P] Organizational concentration of funding.
[P] Maintainer succession plan.
[P] Trademark/branding ownership clarity.
[H] Effective independence from a single vendor.
[H] Whether documented governance corresponds to actual practice.

The Apache maturity model is especially useful here because it makes explicit that mature open source is not just code: it includes licensing, releases, community, consensus building and independence.⁴

Similarly, the Apereo rubric considers governance and management alongside development activity and technical characteristics.³

This matters because an apparently healthy repository can still be fragile if every important decision, credential and release key belongs to one individual.

Support

[A] Public issue tracker available.
[A] Discussion forum available.
[A/P] Chat/community channel available.
[P] Support channel discoverability.
[A] Response time to questions.
[A] Question-resolution time.
[P] Documentation freshness.
[P] Backwards-compatibility policy.
[P] Upgrade/migration documentation.
[P] Supported versions.
[P] Support lifecycle.
[H] Commercial support availability.
[H] Community support capacity.
[H] Training availability.

Support is another area where external context matters.

A project can look inactive on GitHub while having a very active mailing list. Another project can have hundreds of unanswered GitHub issues but excellent commercial support for production users.

The repository tells us something, but rarely everything.

Diversity, inclusion and community culture

These metrics are difficult to collect responsibly and should not simply be scraped from contributor profiles.

CHAOSS nevertheless identifies useful areas to consider as part of the health of an open-source community.²

Potential dimensions include:

[H/P] Inclusive leadership.
[H] Psychological safety.
[H] Newcomer experience.
[P] Inclusive issue labels and terminology.
[H/P] Chat-platform inclusivity.
[H/P] Meeting attendance.
[H/P] Meeting accessibility.
[H/P] Time-zone inclusion.
[H/P] Event accessibility.
[H/P] Event-location inclusivity.
[H] Family friendliness of events.
[H] Conflict resolution and mediation.
[H] Contributor satisfaction.

Some things are worth measuring precisely because they cannot responsibly be inferred from GitHub usernames.

This is an important boundary for an automated evaluator: the existence of data does not imply that collecting or inferring it is appropriate.

Funding and economic sustainability

[A/P] Funding mechanisms documented.
[A/P] GitHub Sponsors/OpenCollective/etc. configured.
[P] Number of sponsors.
[P] Sponsor diversity.
[P] Recurring versus one-off funding.
[P] Funding concentration.
[H] Funding runway.
[H] Number of maintainers paid to work on the project.
[H] Percentage of maintenance work funded.
[H] Dependency on a single employer.
[H] Ability to finance infrastructure/security work.
[H] Availability of long-term institutional support.

A project maintained by one developer in their spare time and a project maintained by five full-time developers may have identical GitHub activity today while having very different sustainability risks tomorrow.

Funding is therefore important, but difficult to reduce to a repository metric.

A .github/FUNDING.yml file tells us that a funding mechanism exists. It says almost nothing about whether the project is economically sustainable.

Ecosystem importance and criticality

Health and importance are also different concepts.

An abandoned project with millions of dependents may be extremely important while being spectacularly unhealthy.

Potential criticality metrics include:

[A] Number of downstream dependents.
[A] Transitive dependency reach.
[A] Reverse dependency centrality.
[P] Number of ecosystems distributing the software.
[P] Number of operating-system distributions containing it.
[P] Number of organizations contributing.
[P] Number of organizations relying on it.
[P] OpenSSF Criticality Score.
[P] Dependency-network centrality.
[H] Use in critical infrastructure.
[H] Availability of realistic substitutes.
[H] Cost of replacing the project.

The OpenSSF Criticality Score is an interesting existing experiment. It combines a range of repository signals into an estimate intended to help identify projects that may deserve particular attention.⁷

But criticality still doesn’t mean quality.

And it doesn’t mean maturity.

This distinction matters when deciding where to invest security or maintenance resources. Sometimes the project we should care most about is precisely the unhealthy one because half the software ecosystem depends on it.

Operational maturity — the missing evidence

And finally we reach the information that a Git repository usually cannot tell us.

This is also where traditional TRL and OSSTRL diverge most strongly.

[H] Number of real-world deployments.
[H] Number of production deployments.
[H] Number of independent organisations operating the software.
[H] Years of production use.
[H] Deployment scale.
[H] Availability/uptime history.
[H] Performance under realistic workloads.
[H] Scalability evidence.
[H] Operational incident history.
[H] Recovery procedures tested.
[H] Upgrade procedures tested in production.
[H] Long-term data migration experience.
[H] Compatibility across supported environments.
[H] External security assessments.
[H] Accessibility assessments.
[H] User references/case studies.
[H] Long-term support commitments.

These are precisely the signals required to make statements resembling traditional high TRL levels.

NASA’s TRL concept progresses toward systems demonstrated and ultimately proven in operational conditions.⁹

GitHub cannot magically provide that evidence.

This is probably the single biggest limitation of any attempt to derive a TRL-like value purely from repository information.

Automation is the difficult part

The interesting challenge is therefore not defining another list of metrics.

The challenge is deciding:

what can be collected automatically;
what can be collected reliably;
what actually means something;
how metrics should be normalized;
how metrics should be weighted;
what information should remain explicitly unknown;
and what combinations of evidence are required before claiming a higher level.

This last point is important.

Imagine a repository with:

excellent documentation;
a Code of Conduct;
issue templates;
a governance document;
a security policy;
lots of GitHub stars;

but no release for four years.

A pure weighted average could still give it a surprisingly respectable score.

That feels wrong.

This is why OSSTRL uses gates in addition to weights.¹²

Some evidence should be prerequisites rather than merely additional points.

For example, documentation should help a project score better, but documentation alone should not compensate indefinitely for the absence of active development, tests, stable releases or a functioning contributor community.

Unknown is not zero

Another lesson from this exercise is that:

missing evidence and negative evidence are different things.

If GitHub doesn’t show a privacy policy, that doesn’t necessarily mean the project has no privacy policy.

If there are no GitHub Releases, the project might publish through Debian, PyPI, npm, Maven, its own infrastructure or somewhere else.

If we cannot discover production deployments, that doesn’t mean there are none.

If the project doesn’t use GitHub Issues, it may be using Bugzilla, Jira, GitLab, a mailing list or another support system.

An automated system therefore needs at least three states:

yes
no
unknown

And probably a fourth one:

not applicable

This sounds trivial, but many scoring systems effectively collapse unknown into no.

That creates a strange incentive: projects that expose more information can actually appear worse because there is more evidence available to evaluate them.

This is also why I think an OSSTRL report should always display coverage/confidence next to the score.¹²

For example:

OSSTRL 7/9
score: 76%
confidence/coverage: 42%

means something very different from:

OSSTRL 7/9
score: 76%
confidence/coverage: 100%

The first result should encourage investigation rather than confidence.

Repository evidence and asserted evidence

A possible next step for OSSTRL would be to use two separate evidence channels. The first one remains completely automatic:

GitHub/GitLab/forge
        |
        v
repository evidence
        |
        v
automatic OSSTRL

A second channel could allow maintainers to provide an osstrl.yaml file containing externally verifiable evidence:

deployments:
  known_organisations: 27
  references:
    - https://example.org/case-study

security:
  external_audit:
    date: 2026-05-12
    report: https://example.org/audit.pdf

support:
  supported_versions:
    - "6.x"

operations:
  production_since: 2018

The distinction would remain explicit:

observed evidence — collected independently from the repository or other public sources;
asserted evidence — provided by the project;
verified external evidence — assertions backed by independent references.

This is similar in spirit to the distinction implicit in initiatives such as the OpenSSF Best Practices programme, where some evidence can be automatically checked while other properties must be declared by the project.⁶

That could bring OSSTRL closer to actual technology readiness without pretending that a GitHub API contains information it simply doesn’t have. But the reality is many projects won’t create a YAML file with the ddetails and why I kept OSSTRL¹² as is.

Different metrics for different questions

Another conclusion from this long quest is that the question itself matters.

When somebody says:

Is this a good open-source project?

they may actually be asking several different questions.

Is it alive?

Look at:

recent development;
recent releases;
responsiveness;
contributor activity;
backlog evolution.

Is it mature?

Look at:

age;
release history;
documentation;
testing;
governance;
compatibility practices;
operational references.

Is it sustainable?

Look at:

contributor concentration;
organizational diversity;
funding;
maintainer turnover;
governance;
succession;
community growth and retention.

Is it secure?

Look at:

vulnerability disclosure;
dependency management;
security automation;
code review;
SAST;
fuzzing;
provenance;
release signing;
known vulnerabilities.

OpenSSF Scorecard focuses deliberately on this particular dimension rather than claiming to measure complete project health.⁵

Is it important?

Look at:

dependents;
deployments;
ecosystem centrality;
downstream usage;
organizational adoption.

This is closer to what OpenSSF Criticality Score attempts to estimate.⁷

Is it open?

Look at:

licensing;
public development;
contribution process;
governance;
decision transparency;
contributor independence.

Is it ready for my use case?

And this one is almost impossible to answer generically. A project can be perfectly mature and still be the wrong software for your requirements. This is why there is probably no meaningful universal ranking of all open-source projects.

No magic score

I don’t think OSSTRL will ever provide an objectively correct answer. And I don’t think it should. There is probably no universal formula where:

42 contributors
+ 8300 stars
+ 93% test coverage
+ SECURITY.md
= mature open-source project

Different software has different needs. Linux, SQLite, a Python library, a Kubernetes operator, a desktop application and a twenty-line Unix tool cannot reasonably be evaluated in exactly the same way.

Metrics are observations. A score is an interpretation of those observations.

This distinction is visible throughout the existing work on OSS health. CHAOSS provides a large collection of metrics and metric models rather than one universal health score.² Apache describes maturity as a collection of characteristics instead of a numerical ranking.⁴ Apereo similarly evaluates a broad set of organizational, community and technical properties.³

That is probably not accidental. OSSTRL¹² is therefore best understood as a first-pass maturity estimator: something that can quickly inspect an unfamiliar repository, expose the evidence behind its result, and highlight where we need to look deeper.

The real objective is not the number.

The useful part is being able to say:

This project looks mature because of these observable facts, we could not verify these other facts, and these are the areas that deserve human investigation.

That, to me, is already much more useful than counting GitHub stars.

And the quest continues.

GitHub — Starring repositories. GitHub presents starring primarily as a mechanism for users to bookmark repositories and discover projects of interest. Star counts can therefore serve as an approximate signal of visibility or interest, but they do not directly measure active usage, production deployment, software quality, maintainability, security or sustainability. Stars are especially problematic when comparing projects from different ecosystems or age groups: an old developer tool, a fashionable JavaScript project and a deeply embedded infrastructure library can have completely different star dynamics. GitHub REST API documentation for starring: https://docs.github.com/en/rest/activity/starring. ↩ ↩²
CHAOSS — Community Health Analytics in Open Source Software. CHAOSS is a Linux Foundation project developing open methodologies, metrics and metric models for understanding the health and sustainability of open-source communities. Its work covers technical activity as well as contributor behaviour, responsiveness, organizational diversity, governance, inclusion, risk, sustainability and ecosystem characteristics. Rather than defining one universal OSS health score, CHAOSS provides a large catalogue of individual metrics and combinations of metrics intended to answer particular questions. This makes CHAOSS a useful illustration of the central problem discussed in this post: open-source health is inherently multidimensional, and metrics only become meaningful when the question being asked is clear. See the CHAOSS overview of metrics and metric models at https://www.chaoss.community/kb-metrics-and-metrics-models/ and the complete catalogue at https://www.chaoss.community/kbtopic/all-metrics/. ↩ ↩² ↩³ ↩⁴
Apereo Foundation — OSS Health and Sustainability Rubric. The Apereo OSS Health and Sustainability Rubric provides a structured methodology for evaluating the health and long-term sustainability of open-source software projects. The rubric contains more than forty assessment criteria spanning areas including Community, Governance, Development, Support, and Security/Privacy. Criteria include project maturity, contributor diversity, responsiveness, governance and management practices, roadmaps, funding, development activity, release consistency, licensing, integrations, documentation, backwards compatibility, support, security review and privacy practices. A particularly useful aspect of the rubric is that it mixes properties that can be inferred from repository evidence with properties that require knowledge about real implementations, organisations, funding and community practices. OSSTRL uses the Apereo rubric as a major source of inspiration but intentionally implements only the subset for which useful evidence can currently be gathered automatically; it does not claim to reproduce an official Apereo score. The rubric is maintained openly on GitHub and is licensed under Creative Commons Attribution 4.0: https://github.com/apereo/oss-rubric. ↩ ↩² ↩³
Apache Software Foundation — Apache Project Maturity Model. The Apache Project Maturity Model describes a collection of characteristics commonly found in mature open-source projects. Rather than reducing maturity to a numerical score, the model examines code, licensing, releases, quality, community, consensus building and independence. Its emphasis on independence and consensus is particularly relevant because technical activity alone does not guarantee a sustainable open-source project: a repository can be technically excellent while remaining completely dependent on one individual or one company. The model therefore provides a useful complement to metrics based primarily on forge activity. https://community.apache.org/apache-way/apache-project-maturity-model. ↩ ↩² ↩³
OpenSSF — Scorecard. OpenSSF Scorecard is an automated security-analysis project for open-source repositories. It evaluates repository configuration and development practices using a set of security-oriented checks and produces results that can be integrated into automated workflows. Scorecard checks cover areas such as code review, branch protection, dependency updates, dangerous CI workflows, fuzzing, licences, maintained status, packaging, pinned dependencies, static analysis, security policies, signed releases, token permissions and known vulnerabilities. Scorecard is an important precedent for OSSTRL because it demonstrates that meaningful repository properties can be estimated automatically while still acknowledging that each individual check is a heuristic rather than proof of complete security. OpenSSF project page: https://openssf.org/projects/scorecard/. Source code: https://github.com/ossf/scorecard. ↩ ↩² ↩³
OpenSSF — Best Practices Badge Program. The OpenSSF Best Practices Badge programme provides projects with a structured set of criteria covering secure development, basic quality practices, change control, vulnerability reporting, build processes and documentation. Unlike a purely automated repository scanner, the badge process combines information that can be checked automatically with declarations provided by project maintainers. This hybrid model is relevant to OSSTRL because many important maturity characteristics — production deployments, support commitments, security audits, governance effectiveness or accessibility practices — cannot be reliably inferred from repository metadata alone. https://openssf.org/projects/best-practices-badge/. ↩ ↩² ↩³
OpenSSF — Criticality Score. Criticality Score is an OpenSSF project designed to estimate the relative criticality or influence of open-source projects. Its model combines observable signals such as project age, contributor activity, participating organisations, commits, releases, issue activity and dependency information. The important distinction is that criticality is not equivalent to project health, quality or maturity. A poorly maintained library can have very high criticality if a large software ecosystem depends upon it, while a healthy and mature specialised project may have little ecosystem-wide criticality. OpenSSF project page: https://openssf.org/projects/criticality-score/. Source implementation: https://github.com/ossf/criticality_score. ↩ ↩² ↩³
Johan Linåker, Efi Papatheocharous and Thomas Olsson — “How to characterize the health of an Open Source Software project? A snowball literature review of an emerging practice.” Published in the proceedings of OpenSym 2022, this literature review surveys research and practitioner work on open-source project health and identifies more than one hundred characteristics grouped across fifteen themes. The paper is useful evidence for the idea that there is no single natural OSS health metric: technical development, community activity, governance, ecosystem relationships, sustainability and other dimensions all contribute different information. The large number of identified characteristics also highlights the practical problem faced by automated scoring systems — selecting a meaningful subset is as important as collecting the data itself. DOI: 10.1145/3555051.3555067. https://doi.org/10.1145/3555051.3555067. ↩
NASA — Technology Readiness Levels (TRLs). NASA uses a nine-level scale for describing the maturity of technology, beginning with basic principles and progressing through proof of concept, validation and demonstration toward technology that has been proven in successful operational use. TRLs originated in the NASA environment before spreading to other space agencies, governments and research-funding programmes. The distinction between repository maturity and actual operational demonstration is particularly important for OSSTRL: Git repository data can provide substantial evidence about software-development maturity, but cannot by itself establish the operational evidence expected at the upper end of a traditional TRL scale. NASA overview: https://www.nasa.gov/directorates/somd/space-communications-navigation-program/technology-readiness-levels/. ↩ ↩²
European Space Agency — Technology Readiness Levels. ESA uses the nine-level TRL scale as part of its technology-development activities and notes that the concept was originally proposed by NASA. In the ESA context, TRLs describe progression from fundamental technology principles through validation and demonstration toward flight-proven or operational technology. The widespread reuse of this common 1-to-9 vocabulary is one reason it provides an attractive conceptual model for an OSS maturity indicator, even though repository-based evidence and traditional TRL evidence are fundamentally different. ESA, About ESA technology programmes: https://www.esa.int/Enabling_Support/Space_Engineering_Technology/About_ESA_technology_programmes. ↩
European Commission — Horizon Europe and Technology Readiness Levels. TRLs are widely used in European Union research and innovation programmes to describe the expected maturity of technologies at different stages of funded activities. Calls may specify the expected TRL at the start or end of a project, distinguishing activities oriented toward research, validation, demonstration, piloting or deployment. This repeated use in European projects makes the 1-to-9 TRL vocabulary particularly familiar to organisations participating in EU-funded research. European Commission, Horizon Europe work programmes: https://research-and-innovation.ec.europa.eu/funding/funding-opportunities/funding-programmes-and-open-calls/horizon-europe/horizon-europe-work-programmes_en. ↩
OSSTRL — Open Source Software Technology Readiness Level, Alexandre Dulaunoy et al. OSSTRL is an experimental open-source application that estimates a readiness/maturity level from 1 to 9 using evidence that can be gathered automatically from a GitHub repository. The current implementation evaluates repository evidence across Community, Governance, Development, Support and Security/Privacy. It produces both a weighted score and a separate confidence/coverage value, then applies readiness gates to prevent easily observable repository artefacts from being sufficient on their own for a high maturity level. The project explicitly presents the result as an estimate rather than a replacement for a formal Technology Readiness Level assessment. Source code, methodology and examples: https://github.com/adulau/osstrl. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
GitHub — Community Profile Metrics. GitHub’s community-profile API reports the presence of several common repository artefacts associated with an accessible open-source project, including files such as a README, licence, Code of Conduct, contributing guidelines, issue templates and pull-request templates. These signals are attractive for automated maturity assessment because they are cheap and consistent to collect. Their limitation is equally important: the presence of documentation proves only that an artefact exists. A CODE_OF_CONDUCT.md file does not demonstrate a healthy community, just as a contribution guide does not prove that external contributions are actually welcomed. GitHub REST API documentation: https://docs.github.com/en/rest/metrics/community. ↩
GitHub — Repository Metrics API. GitHub exposes APIs for several categories of repository statistics, including contributor statistics, commit activity, code-frequency statistics, participation, repository traffic and community information. These APIs make it technically straightforward to collect large quantities of data about public software projects. The difficulty lies in interpretation. Commit counts may include bots or generated changes, forks may never contain original work, and repository traffic may reflect temporary publicity rather than adoption. The availability of a metric should therefore not be confused with its suitability for a maturity score. https://docs.github.com/en/rest/metrics. ↩
CHAOSS — Starter Project Health Metrics Model. The CHAOSS Starter Project Health Metrics Model provides a deliberately small collection of metrics intended to give newcomers an initial view of project health without requiring analysis of the entire CHAOSS catalogue. It includes complementary signals such as release frequency, time to first response, change-request closure ratio and Contributor Absence Factor. The model is relevant to OSSTRL because it demonstrates that even a first-pass assessment benefits from mixing different dimensions: development activity, responsiveness and concentration of contributions reveal different kinds of project risk. https://www.chaoss.community/kb/metrics-model-starter-project-health/. ↩
OpenSSF Scorecard — Check Documentation. The Scorecard check documentation describes the individual security properties evaluated by the tool and the evidence used to estimate each property. Examples include Binary-Artifacts, Branch-Protection, CI-Tests, Code-Review, Contributors, Dangerous-Workflow, Dependency-Update-Tool, Fuzzing, License, Maintained, Packaging, Pinned-Dependencies, SAST, Security-Policy, Signed-Releases, Token-Permissions and Vulnerabilities. The documentation is also a useful example of the limitations inherent in automated metrics: a detectable repository practice is normally a proxy for a desirable security property rather than definitive evidence that the project is secure. https://github.com/ossf/scorecard/blob/main/docs/checks.md. ↩ ↩²
SLSA — Supply-chain Levels for Software Artifacts. SLSA is a framework for strengthening the integrity of software supply chains, particularly the process by which source code is transformed into distributed software artifacts. The specification defines requirements around provenance, build environments and verification so that consumers can obtain stronger assurances about how an artifact was produced. For OSS maturity assessment, SLSA-related evidence provides information that ordinary repository activity does not: a project may maintain source code actively yet have an opaque or weak release pipeline. SLSA specification version 1.2: https://slsa.dev/spec/v1.2/. ↩
SPDX — Software Package Data Exchange. SPDX is an international open standard for communicating information about software packages, components, licences, copyrights and relationships between software elements. SPDX identifiers are widely used for representing licences in machine-readable form, while SPDX documents can also serve as Software Bills of Materials. SPDX is relevant to automated OSS maturity analysis because it transforms parts of software provenance and licensing that were traditionally expressed in unstructured text into information that tools can validate and compare. SPDX specifications: https://spdx.dev/use/specifications/. ↩ ↩²
Free Software Foundation Europe — REUSE Specification. REUSE defines a practical convention for making copyright and licensing information in source-code repositories machine readable. Instead of relying only on a single top-level LICENSE file, REUSE provides mechanisms for associating copyright notices and SPDX licence identifiers with individual files or groups of files. This makes it possible to automatically check whether licensing information is complete and unambiguous across a repository. REUSE therefore provides a stronger automatable legal signal than merely checking that a LICENSE file exists. https://reuse.software/spec/. ↩

Sovereignty Is Engineered, Not Procured

Sat, 06 Jun 2026 04:02:00 +0200

Sovereignty Is Engineered, Not Procured

Europe often asks whether it can build a company like Palantir: a software champion capable of serving intelligence, defence, law enforcement, crisis response, cyber defence, and public-sector decision-making at scale.

The usual answer is that Europe lacks data, capital, talent, or legal room. I do not think this is the full story.

The capacity is there. The data is there. The technical talent is there. The public-sector problems are real, urgent, and interesting. What is often missing is the will to tackle complex programmes seriously, over time, with teams that are allowed to build, fail, iterate, and take responsibility.

Europe does not need a Palantir clone and definitely does not want such a proprietary tool. It needs the capacity to build strategic software for intelligence and security missions without outsourcing the core of its thinking.

The problem is not only procurement

European intelligence and security organisations often buy American intelligence products, American analytics platforms, American cloud stacks, and American operational software. This is sometimes justified by speed, maturity, interoperability, or political convenience. Those arguments are not always false.

But they hide a deeper problem: dependency becomes culture.

Once an organisation accepts that the difficult software will be bought elsewhere, internal teams slowly lose the habit of building. Procurement becomes a substitute for strategy. Legal review becomes a substitute for leadership. Risk management becomes a substitute for execution.

In such environments, the safest answer is always “no”: No, we cannot expose this. No, we cannot publish this. No, we cannot collaborate. No, we cannot build it ourselves. No, legal will not allow it. No, procurement will take too long. No, it is too sensitive.

Some of these objections are valid. Many are excuses.

The result is predictable: Europe keeps producing excellent policy documents about sovereignty while buying the operational substrate of sovereignty from others.

Intelligence software is not magic

The mystique around intelligence software is harmful. Much of the work is not magical. It is hard engineering, data modelling, workflow design, access control, auditability, graph analysis, entity resolution, case management, knowledge management, search, enrichment, automation, feedback loops, and user experience.

These are difficult problems, but they are not impossible problems.

The difficult part is not only technical. It is organisational.

You need teams that understand the mission and the technology. You need product owners who know the analysts’ work. You need engineers who are trusted with real problems, not toy datasets. You need security and legal teams that help build safe ways forward instead of only producing reasons to stop. You need leadership willing to accept that serious internal capacity cannot be built through one-year projects, rotating committees, or PowerPoint roadmaps.

A European intelligence champion would not emerge from a single procurement framework. It would emerge from a culture that rewards building.

The counterexample: agencies that publish

There are public counterexamples.

The NSA has released and maintained open-source software. Ghidra, its reverse-engineering framework, is one of the most visible examples. Apache NiFi and Apache Accumulo also show a pattern: internal capabilities can be released, reused, governed, and improved outside the original classified context. SELinux is another historical example of a security capability that moved into the broader ecosystem.

National Geospatial-Intelligence Agency (NGA) produces a significant numbers of geo-spatial open-source tooling such as MAGE.

GCHQ released CyberChef, a widely used browser-based tool for encoding, decoding, transformation, and data analysis. It also published Gaffer, a graph database framework designed for large-scale entity and relationship analysis.

In Europe, ANSSI has published tools and policy around open source, including CLIP OS and digital forensics tooling. CIRCL’s MISP is a strong European example of an open-source threat intelligence and sharing platform built by practitioners for practitioners.

These examples matter because they show that “sensitive mission” and “public engineering” are not mutually exclusive. You do not publish secrets. You publish reusable infrastructure, generic tooling, schemas, libraries, documentation, and lessons learned.

The public artefact is not the operation. It is the scaffolding that makes the operation more mature.

Open source is not charity; it is capacity building

When an intelligence or cyber agency releases useful software, it is not doing charity. It is doing industrial policy, recruitment, standardisation, quality assurance, and ecosystem building at the same time.

Open source can:

attract engineers who want to work on real problems;
create common standards across agencies and partners;
reduce duplicated development;
allow universities and SMEs to contribute;
make procurement less dependent on single vendors;
improve trust through inspectable code;
turn internal tools into shared infrastructure;
create a training path for future analysts and developers.

This is not about publishing everything. It is about knowing what can be safely published and having the institutional courage to do it.

The irony is that secrecy is often used to protect weak engineering, not sensitive capability. If a tool cannot be shown, documented, tested, or reused, sometimes the reason is not classification. Sometimes the reason is that it is fragile, badly governed, or too dependent on a contractor.

Europe has data, but not enough product culture

European public institutions and trusted national operators already sit close to enormous amounts of relevant data. This includes cyber incident data, vulnerability data, malware metadata, abuse reports, phishing reports, domain and certificate data, passive DNS, DNS telemetry, routing information, NetFlow and other network metadata from trusted infrastructure or ISP-level cooperation, honeypot data, sinkhole data, scanning results, open-source intelligence, sanctions data, company registers, procurement data, satellite data, customs data, border data, law-enforcement data, and diplomatic reporting.

There are also many other sources that do not need to be publicly listed. The point is not to expose them. The point is to recognise that Europe does not lack raw material.

The problem is rarely the absence of data. The problem is the ability to lawfully collect, govern, correlate, enrich, protect, and transform that data into operational products.

A product is not a database. A product is not a dashboard. A product is not a tender. A product is not a pilot. A product is not a research prototype.

A product has users, maintenance, documentation, security boundaries, onboarding, training, ownership, metrics, feedback, and a roadmap. A product survives beyond the first grant. A product has a team.

This is where many European initiatives fail. They are funded as projects, not built as products. They are coordinated as programmes, not operated as capabilities. They produce deliverables, not infrastructure.

The strategic challenge is not only to collect data. It is to build the institutional and technical capacity to turn legally accessible data into timely intelligence, while keeping strong boundaries around sensitive sources, methods, and protected information.

The legal excuse

Europe is very good at finding legal complexity. This is sometimes necessary. Intelligence, defence, cyber defence, and law enforcement must operate under democratic control, fundamental rights, proportionality, and auditability.

But legal complexity cannot become a permanent excuse for inaction.

The role of legal teams should not be to restrict the mission by default. Their role should be to help the organisation achieve its mission lawfully, creatively, and responsibly.

Good legal work is not only about saying what cannot be done. It is about designing the conditions under which useful work can be done: minimisation, compartmentalisation, access controls, retention rules, audit logs, purpose limitation, synthetic data, redaction, disclosure processes, and clear governance.

Law should be part of the architecture. Legal teams should be close enough to the mission to understand the operational need, and close enough to the engineers to help design systems that respect the law while still delivering capability.

The question should not be: “Can we avoid all risk?” The question should be: “How can we use the law to support the mission, reduce risk, and create a defensible path to action?”

A risk-free intelligence system does not exist. Buying a foreign platform does not remove risk. It merely changes who controls it.

The fear of exposure

Many intelligence and security organisations fear exposing how they work. Some of that fear is legitimate. Methods, sources, tasking, and operational priorities must be protected.

But hiding everything creates a second-order weakness: nobody outside the wall can help, and nobody inside the wall is forced to improve.

Open-source publication, public APIs, shared schemas, public documentation, and controlled community engagement do not require revealing operations. They require discipline. They require separating the generic from the sensitive.

That separation is itself a sign of maturity.

If an organisation cannot separate reusable engineering from classified activity, it probably does not understand its own architecture well enough.

What is missing?

What is missing is not a European lack of intelligence. It is a lack of institutional appetite.

More precisely, Europe is missing:

Mission-driven product teams Small, stable teams with engineers, analysts, security people, legal support, and operational ownership.
Long-term technical leadership People who can say no to bad architecture, bad outsourcing, and fake innovation.
A willingness to publish non-sensitive components Open-source software, schemas, libraries, test datasets, documentation, and reference implementations.
Procurement that rewards capacity, not dependency Contracts should build internal competence, not replace it.
Creative legal engineering Lawyers and technologists working together from day one to use the law as a framework for action, not as a default reason for refusal.
Acceptance of managed risk No serious capability is built without risk. The goal is not to eliminate risk but to govern it or even accept it.
A culture of reuse across European agencies Europe does not need twenty incompatible platforms solving the same problem badly.
Operational feedback loops Analysts and investigators must shape the tools they use. Otherwise software becomes theatre.

The strategic choice

Europe can keep buying intelligence software from others and call it pragmatic. Sometimes that will be necessary. But if it becomes the default, Europe should stop pretending that it is building sovereignty.

Sovereignty is not declared. It is engineered.

It is engineered in code repositories, data models, deployment pipelines, documentation, audit logs, and teams that know how to operate under pressure. It is engineered when public institutions learn to build again.

The lesson from NSA, NGA, GCHQ, ANSSI, CIRCL, and others is not that everything should be open. The lesson is that strong institutions can expose selected parts of their engineering without exposing their secrets.

That is what confidence looks like.

Europe has the people. It has the data. It has the problems. It even has successful examples.

What it still needs is the desire to build serious programmes, the courage to accept managed risk, the creativity to use the law as an enabler, and the discipline to turn public-sector software from procurement artefacts into operational capabilities.

A European intelligence champion will not appear because a minister announces one.

It will appear when European organisations decide that building is part of the mission.

Don’t Do Team Meetings

Mon, 27 Apr 2026 12:02:00 +0200

Don’t Do Team Meetings

Regular team meetings are often treated as a default part of work. They are seen as a sign of coordination, alignment, and healthy communication. In practice, they often reveal the opposite.

A recurring team meeting where everyone goes around the room to explain what they did last week is usually not a good use of time. It turns communication into a performance instead of a real exchange of useful information. If the team needs a formal meeting just to learn what people have been doing, that is often a sign that day-to-day communication is already failing.

The problem with “what did you do last week?” meetings

They happen too late

Work should not become visible only once a week in a meeting. If something matters, it should already have been shared when it happened: when a task was completed, when a blocker appeared, when a useful idea emerged, or when help was needed.

Waiting for a meeting to report progress means information is delayed, and delayed information is usually less useful.

They expose a communication issue

If a team depends on a weekly meeting to know what others are achieving, the issue is not a lack of meetings. The issue is a lack of continuous communication.

People should not discover completed work, current priorities, or open questions only during a scheduled call. A healthy team communicates continuously, in context, and in writing when possible. If this is not happening, adding more meetings does not solve the underlying problem.

They are often boring

Most of these meetings are passive. One person speaks, others wait for their turn, and very little real discussion happens. In many cases, people are not truly listening. They are replying to emails, reading messages, or working on something else while the meeting continues in the background.

That is usually a sign that the meeting is not useful enough to deserve full attention.

They scale badly

The more people you add, the worse the meeting becomes.

Each additional participant increases the duration, reduces relevance, and lowers attention. What may be tolerable with three people becomes a waste of time with ten. A long status meeting with many participants often creates very little value for most of them.

A meeting that costs one hour for ten people is not a one-hour meeting. It is a ten-hour cost for the team.

The alternative is simple: share continuously in chat, in the right place, as the work happens.

This is the model we use in our team.

Instead of relying on status meetings, communication happens across several chat rooms:

one global room for the whole team
one fun room for informal exchanges
multiple project-specific rooms

The rule is simple: use the project room first when something is related to a specific project. This keeps information close to the people who need it, while still making it visible to others who want to follow along.

Everyone can join all rooms. The only mandatory ones are the global room and the fun room.

This model has several advantages:

Communication becomes timely

Updates are shared when they matter, not days later. People can react sooner, help sooner, and stay informed without waiting for a calendar slot.

Communication becomes contextual

Project-related discussions stay in project rooms. Team-wide information goes to the global room. Casual conversation has its own place. This reduces noise and makes it easier to find relevant information later.

Communication becomes inclusive without being interruptive

People can read when they have time. They do not need to stop their work for a meeting that may not concern them. They can stay informed asynchronously and still participate when relevant.

There is no need to force reactions. Sharing is enough.

Communication becomes searchable and durable

A chat message leaves a trace. It can be read later, linked, searched, or revisited. A spoken status update in a meeting often disappears as soon as the call ends.

Meetings should be the exception

This does not mean that all meetings are bad. Some meetings are necessary:

to make a decision that requires live discussion
to resolve a conflict or a misunderstanding quickly
to work through a complex topic together
to handle urgent coordination in real time

But a recurring status meeting is rarely the best tool for those cases.

Conclusion

If your team has a weekly meeting just to explain what everyone did last week, the problem is probably not that you need a better meeting. The problem is that you need better communication during the week.

A team that shares continuously in chat is usually more informed, more efficient, and less dependent on rituals that consume time without creating much value.

Do not default to team meetings.

Communicate continuously. Share in context. Keep meetings for the moments when real synchronous discussion is actually needed.

Bring Back RSS for Operational Security

Sun, 22 Mar 2026 11:02:00 +0100

Bring Back RSS for Operational Security

This post expands on ideas I previously presented at Pass the SALT 2024 in my talk Bring Back RSS For Operational Security.¹² The short version is simple: operational security teams still need a reliable way to track change, automate collection, and reduce dependency on closed platforms. RSS already solves much of that problem.

Operational security teams spend an enormous amount of time watching for change.

A new vulnerability advisory is published.
A vendor updates a CSAF document.
A threat actor leaks a new victim.
A trusted researcher posts a new analysis.
A CERT publishes an incident note.
A MISP event is enriched.
A public dashboard changes.

Most of these changes matter because they are new. And yet, in many security teams, we still collect this information in the most fragile way possible: by manually checking websites, relying on algorithmic social platforms, scraping pages that were never designed for machine consumption, or subscribing to closed platforms that add friction instead of removing it.

This is why RSS needs to come back in operational security.

Not as nostalgia. Not as a retro technology for bloggers. But as a simple, robust, auditable, automatable transport format for change detection and information sharing.

RSS was built for exactly this problem

RSS and Atom were designed to describe streams of updates: a list of items, each with metadata such as a title, a publication date, a link, and often a short description. In other words, they were designed to answer a basic operational question:

What changed since the last time I looked?

That question is at the heart of security operations.

A SOC does not only need raw telemetry. It also needs structured awareness of external change:

newly published vulnerabilities
changes in vendor advisories
new threat intelligence reports
updates from trusted researchers
public claims from threat actors
newly published forensic write-ups
software release notes with security impact
updates in shared intelligence platforms

RSS solves this in a way that is boring, open, and dependable. That is precisely why it remains useful.

Security operations need boring technology

Security teams already deal with enough complexity. We do not need every upstream source to invent its own notification model, API semantics, authentication flow, JavaScript-heavy frontend, and rate-limit strategy.

We need more sources that simply publish updates in a standard format.

RSS has several properties that make it especially attractive for operational use:

It is simple

The model is easy to understand: a feed contains entries. Each entry points to something new or changed. There is very little ambiguity about the purpose.

It is machine-readable

Feeds are meant to be consumed by software. This matters because security work quickly becomes repetitive at scale.

It is decentralized

There is no central platform that decides what is visible. Every producer can publish their own feed. Every consumer can subscribe using their own tooling.

It is automatable

Feeds can be polled, filtered, transformed, merged, archived, enriched, and redistributed with minimal effort.

It is auditable

Unlike opaque recommendation engines and engagement-driven timelines, RSS is explicit. You know what you subscribed to. You can replay entries. You can store them. You can build deterministic workflows around them.

In operational security, those properties are not just nice to have. They are essential.

Analyst fatigue is real, and RSS helps reduce it

Security analysts have a broad range of responsibilities: collecting events, detecting threats, triaging signals, analyzing context, and coordinating response. Repetitive collection work adds friction and contributes directly to fatigue. Automation is vital to keep humans focused on judgment rather than polling websites.¹

RSS is one of the easiest ways to automate the collection of external updates without building a fragile dependency on every source.

Instead of asking analysts to remember twenty websites, ten vendor portals, and a handful of social accounts, you can move to a model like this:

subscribe once
normalize once
filter continuously
alert selectively
archive automatically

That is a much healthier model for a SOC than “open browser tabs and refresh all morning.”

RSS is already useful in vulnerability management

One of the most obvious operational use cases is vulnerability intelligence.

The vulnerability ecosystem has changed significantly. NVD is no longer the only practical source of vulnerability information. We now have CNA publications, vendor advisories, CSAF feeds, project-level disclosures, and many other upstream sources. A modern vulnerability workflow must handle multiple sources, not just one canonical database.¹

This is exactly where feeds shine.

A multi-source vulnerability platform can expose a feed per source, allowing teams to:

monitor newly disclosed items
separate vendor-specific updates from generic CVE publication
follow only the ecosystems they care about
trigger enrichment or prioritization pipelines when new entries appear
generate internal dashboards or digests from the latest changes

In Vulnerability-Lookup, this model is natural: every source can expose recent updates through RSS or Atom, which makes it easy to subscribe, aggregate, and operationalize the latest disclosures.³⁴⁵

That matters because vulnerability operations are not only about querying a database. They are also about tracking what changed recently.

RSS is also a strong fit for threat intelligence collection

RSS should not be limited to vulnerability advisories.

Threat intelligence often starts with watching trusted public sources: researchers, incident responders, CERTs, vendor blogs, community projects, bot accounts, and public reporting streams.

A good example is Mastodon. By default, Mastodon accounts expose RSS feeds, which means public accounts can be consumed by standard feed tooling without depending on the platform interface. In practice, that makes it easy to subscribe to high-signal accounts and process updates automatically.¹

This creates useful possibilities:

track public ransomware victim disclosures
monitor researcher reporting on campaigns, malware, or infrastructure
watch topic-specific accounts for changes relevant to your organization
filter by keywords, sectors, product names, or geography
capture public reporting into internal knowledge systems

This is often more reliable than asking analysts to watch social media timelines manually.

RSS works well as an operational building block

One reason RSS deserves a comeback is that it composes well.

It does not need to be the final destination. It can be the transport layer between a source and your workflows.

For example:

Feed -> filter -> dashboard

A self-hosted reader can aggregate feeds from vendors, CERTs, researchers, and internal sources. Analysts can use this as a shared situational-awareness layer.⁶

Feed -> transform -> alert

A script can parse entries, match on keywords, extract URLs, and generate notifications only for relevant updates.⁷

Feed -> enrich -> MISP

A workflow can ingest feed items, pull linked content, create or update MISP events, and extract indicators or context from the referenced material.⁸

Feed -> merge -> publish

Multiple feeds can be combined into a reverse-chronological stream for a team portal, internal digest, or external situational-awareness page.⁹

Feed -> archive -> search

Entries can be stored over time, indexed, and replayed later for investigations, reporting, and retrospective analysis.

That modularity is one of RSS’s biggest strengths. It is not trying to be the whole platform. It is a small, useful component that fits into many platforms.

We should stop confusing “old” with “obsolete”

A recurring mistake in technology is assuming that older protocols are irrelevant simply because they are not fashionable.

RSS is old. So is email. So is DNS. So is syslog.

Age is not a good reason to discard a protocol that still solves a real problem effectively.

In fact, RSS compares favorably to many modern alternatives:

it is easier to consume than most bespoke APIs
it is easier to preserve than social media streams
it is more interoperable than proprietary notification systems
it is easier to self-host than most “intelligence platform” workflows
it creates less lock-in than platform-native feeds and dashboards

The security community often talks about resilience, open standards, and reducing dependency on single vendors. RSS is aligned with all three.

Practical use cases for operational security teams

Here are concrete places where RSS can provide immediate value:

Vendor advisory monitoring

Subscribe to vendor advisory feeds, product security feeds, and CSAF-derived updates. Route them to product owners, vulnerability teams, or sector-specific analysts.

CERT and CSIRT awareness

Track advisories, incident notes, and vulnerability communications from national and sectoral CERTs.

Research monitoring

Follow high-signal blogs, project release feeds, and public researcher accounts.

Threat actor visibility

In some cases, public reporting streams or bot-published updates can be monitored via RSS for early awareness and trend tracking.

Internal SOC dashboarding

Use a self-hosted feed reader or custom dashboard as a collaborative stream of external operational context.

MISP enrichment workflows

Consume feeds, extract linked content, and create or enrich events with contextual reports and indicators.

Executive or sector digests

Merge multiple feeds and publish filtered summaries in text, HTML, or Markdown for targeted internal audiences.

The tooling barrier is very low

Another reason to bring RSS back is that the tooling required is minimal.

You do not need a huge platform migration to start using it well.

A small stack can already deliver a lot of value:

a self-hosted reader for aggregation and sharing
a few scripts for filtering or transformation
MISP integration for enrichment and extraction
a merger tool for combined output
a discovery tool to find feeds on target sites

This is attractive for small and medium teams because the cost of experimentation is low. It is also attractive for larger teams because the result is transparent and composable.

There is no mystery box here. Just feeds, parsers, filters, and workflows.

RSS supports open security ecosystems

Operational security benefits when information can move between communities, tools, and organizations with as little friction as possible.

RSS supports that goal because it is:

open
well understood
easy to generate
easy to mirror
easy to transform
easy to redistribute

That makes it a good fit not only for consumption, but also for publication.

Security projects should publish feeds by default.

If you operate any of the following, you should consider exposing an RSS or Atom feed:

vulnerability databases
advisory portals
research blogs
release notes
incident summaries
MISP exports or derived views
sector-specific intelligence summaries
curated watchlists
public dashboards of recent changes

Publishing a feed is a simple way to make your information more usable operationally.

What the security community should do next

Bringing RSS back does not require a grand initiative. It requires a change in defaults.

If you produce information

Publish a feed.

Do not force users to scrape your site or depend on a proprietary platform just to know what changed.

If you build tools

Support feeds as both input and output.

Do not assume every workflow starts with a REST API and ends in a web UI.

If you run a SOC or CSIRT

Treat feeds as first-class operational inputs, not as a side channel.

Build subscription, filtering, enrichment, and archival workflows around them.

Make RSS and Atom part of the interoperability story again.

Simple export formats often have the biggest practical impact.

RSS is not dead. We just stopped using it enough.

RSS never disappeared. It was simply pushed to the margins while platforms optimized for attention, lock-in, and opacity.

But in operational security, those platform incentives are often the opposite of what we need.

We need explicit subscriptions instead of algorithmic ranking.
We need structured updates instead of noisy timelines.
We need automation instead of manual checking.
We need open formats instead of closed ecosystems.

RSS still provides that.

So yes, bring back RSS for operational security.

Not because it is old-school. Because it is useful. Because it is interoperable. Because it reduces friction. Because it helps analysts focus on what matters. And because a lot of security information is, at its core, simply a stream of changes that deserves a clean and standard way to be consumed.

Footnotes

Pass the SALT 2024 slides, Bring Back RSS For Operational Security: https://www.vulnerability-lookup.org/files/events/2024/20240603-bring-back-rss-for-operational-security.pdf ↩ ↩² ↩³ ↩⁴
Pass the SALT 2024 recording: https://passthesalt.ubicast.tv/videos/2024-bring-back-rss-for-operational-security/ ↩
Vulnerability-Lookup project: https://github.com/cve-search/vulnerability-lookup ↩
Example recent NVD Atom feed: https://vulnerability.circl.lu/recent/nvd.atom ↩
Example recent Siemens CSAF RSS feed: https://vulnerability.circl.lu/recent/csaf_siemens.rss ↩
Newspipe: https://github.com/cedricbonhomme/newspipe ↩
RSS tools collection: https://github.com/adulau/rss-tools ↩
MISP scraper blog post: https://www.misp-project.org/2022/08/08/MISP-scraper.html/ ↩
rssmerge.py example: https://github.com/adulau/rss-tools/blob/master/bin/rssmerge.py ↩

Open Contributions Descriptor — or how to map your contribution in open source, open data, and open standards

Sun, 01 Mar 2026 11:02:00 +0100

Open Contributions Descriptor — or how to map your contribution in open source, open data, and open standards

Open ecosystems thrive on collaboration. Open source software, open data initiatives, and open standards communities all depend on a complex web of contributors, maintainers, organizations, and users working together across domains and borders.

Yet, despite this openness, one surprisingly difficult question remains:

Who contributes what — and how can others participate?

The Open Contributions Descriptor (OCD) was designed to answer exactly that question.

This post explains the story behind the Open Contributions Descriptor, the problem it aims to solve, and how it helps map contributions across the open ecosystem in a way that is both human readable and machine actionable.

Where the idea started

The Open Contributions Descriptor did not emerge in isolation.

The original inspiration came from Mozilla’s contribute.json initiative: https://github.com/mozilla/contribute.json.

Mozilla introduced the idea that projects could publish a small machine readable file describing how people could contribute. It was a simple but powerful concept: contribution entry points should be discoverable automatically rather than buried inside documentation.

Although the project is now archived, the underlying idea remained compelling:

Contribution information should be structured, portable, and published by the project itself.

The Open Contributions Descriptor expands this original vision beyond onboarding contributors to a single project and generalizes it across:

open source
open data
open standards
broader open ecosystems

In a way, Open Contributions Descriptor (OCD) can be seen as a natural evolution of that early experiment, extending contribution metadata from project contribution guidance to ecosystem mapping.

The problem: visibility in a fragmented open ecosystem

Open ecosystems are rich but fragmented¹.

Today, information about contributions is scattered across many places:

Git repositories
README files
governance documents
mailing lists
project websites
data portals
standards organizations
issue trackers
funding reports

Each project documents participation differently or sometimes not at all.

As a result:

Contributors struggle to understand how to get involved.
Organizations cannot easily demonstrate their open contributions.
Communities lack visibility into dependencies and relationships.
Researchers and policymakers cannot map the real impact of openness.
Automated catalogues of open initiatives are difficult to build.

Ironically, while open projects publish code and data transparently, the structure of contributions themselves remains opaque or unknown.

A recurring realization at FOSDEM

Every year, attending FOSDEM is an inspiring experience.

Walking through the corridors, talking to maintainers, and visiting project stands inevitably leads to the same realization:

I constantly discover mature, impactful open source projects I had never encountered online before.

Projects with active communities, real deployments, and years of development somehow remain invisible to traditional discovery mechanisms.

They exist. They are open. They are active.

Yet they are hard to find unless you physically meet the people behind them.

This recurring experience highlights a missing piece in the open ecosystem:

the discovery layer is incomplete.

Search engines index code. Platforms index repositories. Conferences reveal communities. But there is no universal, structured way for projects to declare:

who they are
how they operate
how others can participate

There is a missing key, not to access the code, but to understand the collaboration around it.

Beyond open source: a shared challenge

The challenge is not limited to software.

Across ecosystems we see similar issues:

Domain	Example Questions
Open Source	Who maintains the project? Who funds development?
Open Data	Who produces the dataset? Who curates it?
Open Standards	Who participates in working groups? Who implements the standard?
Research	Which institutions contribute to which initiatives?

These domains overlap constantly. A single organization may:

maintain open source tools
publish open datasets
contribute to standards bodies
depend on other open projects

But there is no simple, structured way to describe these relationships consistently.

The hidden structural problem: centralized directories

Another, less visible issue exists in today’s open ecosystem: centralized discovery.

Many catalogues, registries, and directories attempt to index open projects. While useful, they often share a structural limitation:

A single platform or organization becomes the gatekeeper of discovery.

In practice, this means:

inclusion depends on platform policies
metadata formats are platform specific
projects must register manually
ecosystem visibility depends on maintaining accounts in external systems
long term sustainability relies on the continued existence of one operator

Even in open ecosystems, discovery frequently depends on a central directory holding the “golden key” to visibility.

This creates several risks:

single points of failure
loss of neutrality
vendor or platform lock in
incomplete ecosystem representation
barriers for smaller or independent initiatives

Openness should not depend on a single registry.

The idea: describe contributions as first class metadata

The Open Contributions Descriptor (OCD) introduces a simple idea:

Contributions themselves should be described using an open, structured, machine readable format published directly by the project.

Instead of embedding contribution information informally in documentation, projects publish a descriptor file that answers:

What is this initiative?
What type of openness does it represent?
Who contributes?
How can others contribute?
What roles exist?
How are decisions made?
Where are the contribution entry points?

The goal is not to replace existing documentation but to standardize discovery and mapping.

A standardized discovery location

To make automated discovery reliable, the descriptor is published in a predictable location using a well known URI.

The Open Contributions Descriptor (OCD) is stored as a JSON document named:

.well-known/open-contributions.json

This follows the established .well-known convention defined by RFC 8615, which allows services and metadata to be discovered automatically at standardized paths on a domain.

By placing the descriptor at a well known location:

crawlers know exactly where to look
projects remain in control of their metadata
discovery becomes interoperable across platforms
no registration in external directories is required

To formalize this approach, a registration request for the open-contributions.json well known URI has been submitted to IANA:

https://github.com/protocol-registries/well-known-uris/issues/78

This step is important because it moves the descriptor from an informal convention toward an Internet recognized discovery mechanism, reinforcing long term interoperability and neutrality.

Decentralized discovery by design

A key property of the Open Contributions Descriptor is directory independence.

The descriptor lives with the project or organization itself, not inside a centralized platform.

This changes the discovery model fundamentally:

Traditional Model	OCD Model
Register project in a directory	Publish descriptor in repository
Directory owns metadata	Project owns metadata
Central authority curates	Anyone can crawl
One catalogue	Many interoperable catalogues
Platform dependency	Ecosystem independence

Anyone can build a crawler that discovers descriptors across repositories, websites, or data portals.

There is no central registry required.

Multiple catalogues can coexist:

research indexes
public sector inventories
community driven directories
organizational dashboards
academic analysis platforms

This mirrors the architecture of the web itself:

No single organization owns websites. Search engines discover them.

The Open Contributions Descriptor applies the same philosophy to open collaboration.

Design principles

When designing the Open Contributions Descriptor, several principles guided the work.

Domain agnostic openness

The format works across:

open source
open data
open standards
open research
open infrastructure

It avoids domain specific assumptions while remaining expressive.

Human readable first

The descriptor is meant to be understandable without tooling.

A contributor should be able to open the file and immediately understand:

who is involved
how participation works
where contributions happen

Machine readable by design

At the same time, the format is structured so that tools can easily:

parse descriptors
crawl repositories
build catalogues
map ecosystems
analyze contribution networks

This enables automation without sacrificing clarity.

Lightweight adoption

Projects should not need governance reform to describe themselves.

Many existing directories and metadata formats are designed by committees attempting to normalize the diversity of open ecosystems through rigid governance models. While often well intentioned, they tend to introduce complex requirements, mandatory classifications, approval workflows, or artificial eligibility rules that projects must satisfy before being listed.

In practice, this leads to several problems:

projects must adapt their governance to fit the directory rather than the reverse
contributors spend time complying with administrative requirements instead of building software or data
smaller or unconventional projects are excluded because they do not match predefined models
innovation is constrained by bureaucratic assumptions about how projects should operate

Over time, such rules unintentionally reduce the usefulness of directories themselves. The more constraints imposed, the less representative the catalogue becomes.

The Open Contributions Descriptor takes the opposite approach.

Instead of committees defining how projects must behave, projects simply describe how they already work.

There is:

no approval process
no governance validation
no mandatory organizational structure
no centralized interpretation of legitimacy

The descriptor lowers the barrier to participation by adapting to reality rather than attempting to standardize it.

Independence and sovereignty

Perhaps most importantly:

Projects remain sovereign over how they describe themselves.

No platform approval is required. No centralized authority controls visibility. No organization holds the authoritative directory.

Descriptors enable an ecosystem where discovery emerges organically from openly published metadata.

What the Open Contributions Descriptor enables

Mapping the open ecosystem

Imagine being able to automatically discover:

all projects maintained by a given organization
datasets linked to specific software
standards implemented by certain communities
contribution entry points across ecosystems

Descriptors allow building living maps of openness without centralized ownership.

Easier onboarding for contributors

New contributors often ask:

Where do I start?
Who should I contact?
What skills are needed?
How do decisions work?

Instead of searching multiple documents, a descriptor provides a structured overview.

Transparency and recognition

Organizations increasingly want to demonstrate their participation in open ecosystems.

The descriptor allows them to clearly expose:

roles
responsibilities
contributions
collaboration models

This improves recognition without requiring manual reporting or third party platforms.

Machine discoverable catalogues, plural not singular

One of the core objectives is enabling automated catalogues of:

open source projects
open datasets
open standards initiatives

Importantly, there is not one catalogue. Anyone can build one. Competition, diversity, and experimentation become possible because the metadata layer is open and decentralized.

A simple mental model

Think of the Open Contributions Descriptor as:

package.json for contributions
robots.txt for openness
metadata for collaboration
DNS for open participation

It tells both humans and machines:

“Here is how this open initiative works and how you can participate.”

Example use cases

Open source project

A project publishes an OCD file (MISP project open-contributions.json file) describing:

maintainers and governance
contribution guidelines
communication channels
funding or supporting organizations

Tools can automatically include it in multiple independent catalogues.

Open data platform

A dataset provider describes:

data producers
curators
update responsibilities
contribution workflows
licensing and reuse expectations

Researchers can discover participation opportunities instantly.

Open standards working group

A standards initiative describes:

working groups
participation model
implementation communities
decision processes

Implementers gain clarity without navigating institutional silos.

Why a standard matters

Without a shared descriptor:

every ecosystem reinvents metadata
automation becomes brittle
discovery remains centralized or manual

A common format enables interoperability between communities that historically evolved separately but now collaborate closely.

The Open Contributions Descriptor aims to become a common language for openness without central control.

Open by design

The specification itself is openly developed and available here:

https://github.com/ossbase-org/Open-Contributions-Descriptor

The goal is community driven evolution:

feedback from open source maintainers
adoption by open data platforms
experimentation by standards bodies
tooling built by ecosystem builders

What comes next

The real value of the Open Contributions Descriptor will emerge through adoption and tooling, including:

decentralized ecosystem crawlers
contribution dashboards
organizational impact mapping
research analysis
federated discovery platforms

We envision a future where understanding the open ecosystem becomes as easy as querying a search engine, powered by structured contribution metadata published at the source.

Conclusion

Open ecosystems depend on collaboration, but collaboration itself is still poorly described and too often centrally indexed.

The Open Contributions Descriptor is a small but important step toward making openness discoverable, understandable, decentralized, and measurable.

By standardizing how contributions are described, we can:

lower barriers to participation
increase transparency
preserve ecosystem independence
avoid centralized gatekeeping
recognize contributors
map the global landscape of open collaboration

If open source made code visible, and open data made information visible, the next step is clear:

Make contributions visible without giving anyone the golden key.

Contributions, feedback, and experimentation are welcome because describing openness should itself be open.

Git repository of the Open Contributions Descriptor: https://github.com/ossbase-org/Open-Contributions-Descriptor
Online tool to browse or create/edit Open Contributions Descriptor file: https://ossbase-org.github.io/ocd-viewer/app/home.html - Git repository https://github.com/ossbase-org/ocd-viewer
GitHub organisation generator to Open Contribution Descriptor format: https://github.com/ossbase-org/Open-Contributions-Descriptor/blob/main/bin/github-to-ocd.py
Discourse topic about OCD format.
A sample OCD file for the MISP project.

The term fragmented is often perceived negatively, suggesting disorder or inefficiency. In open ecosystems, however, fragmentation is largely a strength. It reflects diversity, independence, resilience, and experimentation across communities rather than centralized control. The challenge is therefore not to eliminate fragmentation, but to make it discoverable and understandable without reducing its autonomy. ↩

Acknowledging Reality in Vulnerability Disclosure

Sun, 08 Feb 2026 13:02:00 +0100

Full Disclosure Still Exists and That’s Exactly the Point

Disclaimer: This post is grounded in personal experience and roughly 25 years of interaction with vulnerability management, across vendors, researchers, operators, CERTs, and open communities. It does not claim neutrality or theoretical purity. It reflects what repeatedly emerges when disclosure leaves policy documents and meets reality. In other words, this is my bloody personal blog, not an official statement.

Every few years, vulnerability disclosure is declared settled. We are told that the ecosystem has matured, that coordinated disclosure is the answer, and that whatever remains outside this model is either irresponsible, obsolete, or simply irrelevant.

And yet, full disclosure is still here.

Not as a historical artifact, not as a provocation but as an active, lived practice that continues to coexist with other disclosure models.

This blog post explains why this coexistence matters, why the evolution of vulnerability disclosure is not linear, and why initiatives like GCVE deliberately choose to support all disclosure models instead of promoting a single “correct” one.

The Myth of Linear Progress in Disclosure

A common narrative goes like this:

We started with full disclosure → we learned better → we now do responsible or coordinated disclosure.

This framing is comforting. It suggests progress, maturity, and consensus. It is also misleading.

In reality, vulnerability disclosure did not evolve along a single axis.

What we have instead is a non-linear space of practices, shaped by:

Legal constraints
Power asymmetries
Time pressure
Risk tolerance
Economic incentives

The disclosure landscape includes, and continues to include:

Full disclosure
Responsible disclosure
Coordinated disclosure
Vendor-led disclosure
Third-party publication
Silent or delayed disclosure
Federated or community-driven publication

These models exist in parallel, not as steps in a staircase.
They are chosen, combined, or abandoned depending on context.

Economics: The Hidden Driver of Disclosure Models

Vulnerability disclosure is not only a technical or ethical process.
It is also an economic one.

Disclosure mechanisms range from:

Gratis, volunteer-driven reporting
Academic or community research
Contractual security assessments
Paid vulnerability programs
Expensive, highly structured bug bounty processes

Each of these comes with:

Different expectations
Different timelines
Different power relationships
Different notions of “responsibility”

A researcher working for free does not operate under the same constraints as:

A consultant under contract
A bug bounty hunter optimizing return on investment
A vendor-funded security team

Economic incentives shape:

When vulnerabilities are disclosed
To whom they are disclosed
Under what conditions
With what level of detail

Ignoring this economic dimension leads to unrealistic disclosure policies that assume goodwill, time, and resources are evenly distributed. They are not.

Actors Are Not Rational and Not Aligned

Another recurring simplification is the idea that vulnerability disclosure is a cooperative game between rational actors working toward the same goal.

It is not.

Vendors balance security, liability, brand perception, and business continuity.
Researchers operate under ethical pressure, legal uncertainty, time constraints, and economic reality.
Users are downstream actors with limited visibility and little bargaining power.
Intermediaries (CERTs, CSIRTs, platforms) act under mandates that vary widely across jurisdictions.

These actors do not share the same incentives, and they are not playing the same game.

So when someone says:

“The legal framework will solve it”
“Just do coordinated disclosure”
“If it’s not coordinated, it doesn’t exist”

What they are really doing is reducing the problem space to the subset they are comfortable managing.

The remaining cases do not vanish. They simply become unaccounted for.

Why GCVE Exists

GCVE was not created to replace existing identifiers, processes, or disclosure norms.

It was created to support all disclosure models, including:

Centralized systems
Decentralized or federated approaches
Vendor-driven workflows
Independent or community-based publication

GCVE explicitly does not take sides in these tensions.

Instead, it assumes something pragmatic:

Vulnerability information exists regardless of how or whether it was disclosed “properly”.

The purpose of GCVE is not to normalize behavior, but to ensure that once vulnerability information exists, it can be referenced, processed, and consumed.

Ignoring inconvenient disclosures does not improve security. It only weakens collective awareness.

Freedom, Accessibility, and Security Intelligence

One of the more controversial aspects of GCVE is the level of freedom it gives to GNAs (GCVE Numbering Authorities).

This freedom is deliberate.

Cybersecurity intelligence does not improve by keeping information unknown.
It improves through accessibility, correlation, and contextualization.

For users, defenders, and analysts, the central question is not:

“Was this vulnerability disclosed in the ideal way?”

It is:

“Can this vulnerability affect me, my systems, or my dependencies?”

Without accessible information:

Risk cannot be evaluated
Impact cannot be assessed
Mitigations cannot be prioritized and performed

GCVE is built on the idea that users must be able to access vulnerability information, even when the disclosure path is imperfect, contested, or economically asymmetric.

Freedom here does not mean absence of accountability.
It means not blocking information at the source, while allowing consumers to decide how to interpret and trust it.

Why GCVE Uses BCPs Instead of Enforcement

A frequent question is:

Why don’t you require GNAs to follow strict rules?

Because strict enforcement inevitably creates:

Gatekeepers
Central authority
Single points of failure
Implicit power over publication

GCVE instead defines Best Current Practices (BCPs):

Descriptive rather than prescriptive
Transparent rather than coercive
Evolvable rather than rigid

This approach does not prevent:

Public evaluation of GNAs
Rating or scoring their behavior
Highlighting poor or exemplary practices
Making trust an explicit, visible signal

What it avoids is using access control as governance.

Freedom is uncomfortable (and many of us know that fact). It allows outcomes that some actors will strongly disagree with.

But it also allows vulnerability information to exist before consensus, outside institutional comfort zones, and without requiring permission.

“Federation Is Dangerous”, We’ve Heard This Before

Some criticism around GCVE focuses on the perceived danger of federation: fragmentation, balkanisation, loss of control.

These arguments are not new.

They closely mirror the concerns raised when Git was introduced:

“It will fragment codebases” The Promises and Perils of Mining GitHub, 2014
“There will be no single source of truth” Version Control Tools, Martin Fowler, 2010
“People will do the wrong thing” What’s Wrong with Git? A Conceptual Design Analysis, 2013

History suggests otherwise. Federation does not remove coordination it relocates it.

And to be clear: GCVE does not mandate federation.
Centralized models remain fully supported.

As a side note: if GCVE reaches even 1% of Git’s success, we would already consider that a major achievement. (Yes, that is both a joke and a realistic benchmark.)

GCVE and a Non-Reductionist View of Disclosure

Saying “this disclosure model no longer exists” does not make it true.
It only narrows the analytical lens.

GCVE takes a non-reductionist approach by focusing on what vulnerability information needs in practice:

Machine-readability
Stable identifiers
Open formats
Automatic processing
Interoperability across tools and ecosystems

GCVE is designed as an open standard enabling:

Correlation across datasets
Automated ingestion
Enrichment by third parties
Integration into security tooling

This applies equally to:

Proprietary software
Open source software
Hybrid supply chains
Federated ecosystems

The objective is not to enforce a single disclosure workflow, but to ensure that all vulnerability information (regardless of origin, model, or economic context) can participate in the same analytical space.

Complexity Is the Reality. Not the Problem.

Vulnerability disclosure is messy. It is legal, economic, technical, political, and human.

Any framework that assumes otherwise will fail at the margins — precisely where many real-world vulnerabilities exist.

GCVE does not attempt to simplify this reality away.
It attempts to acknowledge it, structure it, and make it usable.

Not by declaring one model correct,
but by accepting that security depends on visibility, not denial.

That is not a weakness.

It is the point.

The Art of Pivoting - Techniques for Intelligence Analysts to Discover New Relationships in a Complex World

Sat, 20 Dec 2025 09:02:00 +0100

This open source book explores how intelligence and cyber-security analysts can uncover hidden links between threat actor infrastructure and ongoing investigations by pivoting on both classic and unconventional indicators — many of which are often overlooked. The material is grounded in empirical, field-tested strategies used in cyber-security, digital forensics, cyber threat intelligence, and intelligence analysis more broadly.

I released the first version of this book following the FIRST.org CTI Conference 2025 in Berlin, where the initial idea for the project emerged.

Our goal is to provide analysts with a practical toolkit of analytical methods, supported by real-world examples, to enhance investigative workflows without locking them into a single mindset, strict model, or overly rigid technical strategy. Instead, the book encourages creative exploration, data-driven reasoning, and the use of diverse data points — from traditional IOCs to subtle metadata traces — as part of a flexible and repeatable analytical process.

The approach presented throughout this book is intentionally built upon open-source tooling, most notably the MISP threat intelligence platform and the AIL Project. By relying on transparent and widely adopted tools, every technique described here can be reproduced, validated, and reused by analysts, researchers, educators, or incident response teams. This ensures that the methodology is not theoretical or proprietary, but openly verifiable, community-driven, and designed to evolve. The book itself follows the same philosophy: it is an open, living document, publicly versioned, and contributions are welcomed directly via Git. Readers are encouraged to experiment, improve, and extend the content, making the entire workflow repeatable, auditable, and collaborative within the wider defensive security community.

Background Story

This book grew out of an iterative, hands-on process tightly coupled with our day-to-day work. Rather than starting from a fixed theory, it evolved alongside real investigations—tracking threat actors, uncovering infrastructure, and experimenting with unconventional pivoting techniques as new challenges emerged.

Each discovery fed back into our tooling: ideas were tested, adjusted, sometimes discarded, and often refined through repeated use. This constant loop of observation, experimentation, and validation shaped both the content of the book and the evolution of the tools supporting it.

Much of this work happened in motion—on trains during daily commutes, between incidents, or while reviewing fresh data. That constraint encouraged pragmatism: techniques had to be simple enough to apply quickly, yet powerful enough to reveal meaningful connections. The result is a book that reflects continuous learning in practice, grounded in real-world analysis rather than static models.

🔗 PDF - The Art of Pivoting
🔗 Source of the book in Markdown (if you want to contribute ;-)

How to Choose an Open Source Project for the Long Term

Sun, 25 May 2025 10:02:00 +0200

How to Choose an Open Source Project for the Long Term

version 1.0 - 25th May 2025

Many of us face the challenge of selecting open source projects for long-term use. This could involve choosing dependencies for your own open source project, or simply selecting software you plan to run and rely on over time.

After experiencing multiple failures, disappointments with projects that turned proprietary, or even the complete disappearance of some repositories, I decided to compile a list of parameters, indicators, and signals that might help identify solid, sustainable open source projects, as well as warning signs that could indicate potential risks.

CLA - Contributor License Agreement

One of the first and most important parameters to consider is the CLA (Contributor License Agreement). As you may know, a CLA is a legal tool but it can be misused to lock in contributions while allowing the original creator (often an organization, but not always) to relicense the work under any terms they choose.

In my personal experience with CLAs over the past 25 years, CLAs are just tools invented by lawyers to exploit human contributions.

If you see a CLA in an open source project, it’s already a strong signal that the project might eventually be relicensed, shift its objectives, or even be rebranded by a commercial entity that views open source merely as a marketing vehicle and nothing more.

If someone tells you that a CLA is there to protect you and your contributions, it’s complete bullshit. Honestly, the CLA was one of the biggest screw-ups of the FSF, it legitimized a bad practice and gave corporate borgs a free pass to exploit it for years. If you want to dig deeper, check out these excellent resources: Why Your Project Doesn’t Need a Contributor Licensing Agreement, the CLA-Free Initiative, and Seriously, don’t sign a CLA.

Software can also be proprietarized even without a CLA just like it happened with Benthos. But CLAs are usually there to protect organizations, not contributors, especially shielding them from potential litigation. So yes, CLAs are strong indicators of possible bad practices down the road.

On the other hand, seeing a DCO (Developer Certificate of Origin) is usually a good sign. It’s not a transfer of ownership, but simply a statement that you agree (and have the right) to have your contribution included in the open source project.

From a contributor’s perspective, this is a positive sign, it shows that contributors are respected and that the project is focused on building a healthy, sustainable community for the long term.

Does the project merge pull requests from outside their organization?

It’s very common to see projects run by a specific organization that don’t accept any contributions from external contributors, only merging pull requests from authors within their own company. Even good contributions often get rewritten, and the original pull request is closed with a comment saying it was “merged,” even though it wasn’t.

This is a classic tactic used by organizations that avoid CLAs just to appear friendly to contributors, while still sidestepping legal risk and keeping full ownership of the codebase which makes relicensing easier down the line.

Does the project interact with contributors and especially how?

Another strong indicator of a project’s long-term health is how it interacts with contributors. Are external contributors welcomed into the development process, or are they quietly pushed aside? Are they included in discussions about design decisions or the direction of a pull request, or is everything decided behind closed doors?

Pay attention to how the maintainers respond to contributions. When a pull request is rejected, is there a respectful, constructive explanation, or just silence or a vague dismissal? Do maintainers engage with feedback and questions in the issue tracker or discussion forums?

A healthy open source project values its community. Transparency, respectful communication, and public discussions are signs of a project that is likely to grow and survive. If you see a pattern of gatekeeping, dismissiveness, or lack of documentation around decision-making, that’s a red flag for long-term sustainability.

Is the open source license a strong indicator of sustainability?

At first, I used to think that using a copyleft-style license was a strong sign of long-term sustainability. But nowadays, I’d say it’s not a reliable indicator on its own.

Of course, the license should be a proper free license, approved by the FSF or OSI, but that’s just the baseline for choosing an open source project. The type of open source license alone doesn’t guarantee longevity or a healthy project.

Summary

If you see a CLA, avoid the project, especially if you need to rely on it for the long term.
If you see projects that never merge contributions and instead rewrite them, stay away, they’re a bad bet for long-term use.
If a project’s handling of contributions is hidden behind closed doors, that’s another clear reason to avoid it.

Additional Notes

I may update this article from time to time to add more strong indicators that can help others choose and evaluate open source projects for long-term use.
Can these indicators be automatically analyzed to create a scoring system for open source projects? I don’t think so, there’s a strong element of perception and context in this kind of analysis. And honestly, I suspect organizations would quickly start gaming the system just to get a better score.

Le Sillon Fictionnel en livret PDF et EPUB

Sun, 23 Feb 2025 15:02:00 +0100

J’ai toujours des idées à la con… Il y avait une issue sur GitHub pour créer un petit livret en PDF et EPUB de notre brol sillonesque. L’optimisme est toujours l’apanage des fous. Comme le chat n’était pas en super forme, je me suis dit que travailler sur l’ordinateur serait facile tout en lui tenant compagnie.

Je commence en me disant qu’une conversion de pages HTML vers un livre PDF serait simple. C’était sans compter l’essence même d’un site web avec des pages en Markdown. Ces pages sont uniques. Concaténer n’est pas une solution. Donc, on démarre avec un petit programme Python pour rassembler le tout.

Puis viennent les notes de bas de page avec des références uniques… On se dit qu’il suffit d’une indexation globale, rien de bien méchant. On pense : « OK, il reste 10 minutes et c’est ficelé. » Mais là, on se rend compte que la conversion Markdown vers LaTeX, c’est bien, sauf qu’il faut retravailler le TeX pour rendre le tout lisible… et puis survient le cauchemar des tailles et formats d’images.

L’optimisme reprend le dessus grâce au super logiciel libre Pandoc… On avance, mais les images restent un foutoir innommable. On découvre que Pandoc fait du Lua et qu’on peut filtrer/modifier les figures. Allez, on se remet au Lua. Puis on tombe sur d’autres joyeusetés, comme la police EB Garamond qui ne passe pas via Fontconfig… et j’en passe.

Mais au final, après quatre litres de thé noir du Mozambique, un chat qui vous fixe bizarrement et quelques expérimentations, ça fonctionne ! Avec, en prime, Le Sillon au format EPUB pour les liseuses.

Gaining Visibility in the Algorithmic-based Internet by Reclaiming Your Space

Thu, 02 Jan 2025 15:01:00 +0100

If you are writing, one of your primary objectives is to be seen and read—two distinct but interconnected goals. Visibility helps your work reach a wider audience, which can lead to more readers engaging with your content. However, in today’s Internet landscape, visibility is shaped by algorithms on social networks, search engines, and advertising networks. These systems often prioritize content that aligns with their business interests, rather than purely the quality or relevance of the material.

The traditional bookstore model offers an insightful comparison. In the past, a bookseller might carefully curate their inventory based on relationships with publishers or their own judgment of quality and market interest. As a reader, you could walk into a bookshop, browse the shelves, or explore a table displaying new releases. Often, a thoughtful recommendation from the bookseller could guide your choice. If a book sparked your curiosity, you might purchase it, and, if it resonated, spend time reading and reflecting on its reading.

In the algorithmic age, or perhaps more accurately, the digital advertising age, the human touch of discovery has been replaced by calculated exposure. Content is surfaced not by serendipity or personal curation but by systems optimised to serve business objectives, often prioritizing engagement metrics over quality.

We often hear that to stand out in this environment, authors or writers must adopt a strategic approach, blending authenticity with a deep understanding of how algorithms operate. To be honest, that’s complete bullshit. The content that is most visible today is rarely the most authentic or useful. It’s simply the content that can generate clicks and capture brain time for advertisers.

I recently rediscovered an old backup of logs from my web server from the early 2000s and compared them with the current logs from 2024. The differences are striking. Back then, around 80% of the access was generated by actual users opening URLs in their browsers, while the remaining 20% was machine crawling or other noise.

Today (2024), noise accounts for 90% of the accesses to my blog posts. This noise primarily comes from:

Trending bots attempting to determine whether a link is interesting enough to include in their algorithms to notify customers that the information is relevant. Companies like Hootsuite, Zoho, Ahref/Yep and many others operate in this space—though I suspect they rarely, if ever, actually read the content. It seems more about branding trends than genuine readers engagement.
Aggressive crawling bots, often associated with AI or linguistic projects, use user-agents reference that provide vague or meaningless explanations of their purpose. Companies like Facebook and Amazon are among the most common in this space. However, it’s clear that your writing will never actually appear on their platforms—it’s simply harvested to serve their data-gathering efforts and refine their own content.
Search engine bots, like Google’s, crawl your pages and might include them in their index weeks or months later. However, don’t expect to appear in the top ten results unless your content is an exact match—and even then, if you’re not part of their advertising network, you’re likely out. On a side note, the SEO industry has effectively destroyed and fucked-up the organic nature of the Internet.
Security bots brute-force attempts, which are increasingly difficult to differentiate from legitimate activity. Many security vendors operate across multiple domains, including exploitation or reselling their data feeds for purposes beyond simply notifying website owners of vulnerabilities.
Mastodon “pre-fetching” URLs, which provides no indication of how many people actually read the content. The overhead can be significant, especially if your post is boosted by an account with many followers, as it’s simply the Fediverse server performing a GET request. Out of curiosity, I analysed a specific URL that was shared only on the Fediverse. It received approximately 34,000 GET requests, yet this translated to just two actual users reading the content.
Pre-fetching bots designed to display your content within ad-supported interfaces. This practice is increasingly common, with bots often testing how the content fits different devices. Unsurprisingly, this doesn’t benefit the content creator in any meaningful way. Instead, it’s aimed at keeping users within the ad-supported application, preventing them from venturing into the broader Internet beyond the confines of these advertising-driven ecosystems.

Less than 10% of the remaining entries in the logs represent actual users browsing and reading the content (and that’s without delving into questions about attention span or whether the content is truly read beyond the title). This 10% is an optimistic estimate based on this quick analysis.

How did we go from an Internet where 80% of the traffic came from genuine readers to a mere 10%, with the rest being noise? Have we really spent the last twenty years investing in Internet routing, bandwidth, server storage, hardware, and energy only to support access via advertising-gated platforms? In doing so, we’ve limited the original promise of the Internet: providing diversity and access to a wealth of knowledge.

What would be the strategy to return to the original promise of the Internet? Blogrolls, random access to blog posts or websites, RSS feeds, or perhaps running your own server? I’m still exploring, but I’m trying to contribute my part to that original vision.

We’ve set up a book club aligned with this promise called le sillon fictionnel. The site is now one year old, and we have 34 followers on Mastodon. According to the logs, we have some actual readers, despite the 95% of noise generated by bots.

Alexandre Dulaunoy - adulau - Home Page

How mature is this repository? My long quest for open-source software metrics

How mature is this repository? My long quest for open-source software metrics

Metrics everywhere

The TRL idea

OSSTRL

What can we measure?

Repository identity and discoverability

Popularity, visibility and adoption

Development activity

Contributors and community sustainability

Issues and bug management

Pull requests and code-review practices

Releases

Code and engineering quality

Dependencies and software supply chain

Security

Licensing and legal clarity

Governance

Support

Diversity, inclusion and community culture

Funding and economic sustainability

Ecosystem importance and criticality

Operational maturity — the missing evidence

Automation is the difficult part

Unknown is not zero

Repository evidence and asserted evidence

Different metrics for different questions

Is it alive?

Is it mature?

Is it sustainable?

Is it secure?

Is it important?

Is it open?

Is it ready for my use case?

No magic score

Sovereignty Is Engineered, Not Procured

Sovereignty Is Engineered, Not Procured

The problem is not only procurement

Intelligence software is not magic

The counterexample: agencies that publish

Open source is not charity; it is capacity building

Europe has data, but not enough product culture

The legal excuse

The fear of exposure

What is missing?

The strategic choice

Don’t Do Team Meetings

Don’t Do Team Meetings

The problem with “what did you do last week?” meetings

They happen too late

They expose a communication issue

They are often boring

They scale badly

A better model: continuous sharing

Communication becomes timely

Communication becomes contextual

Communication becomes inclusive without being interruptive

Communication becomes searchable and durable

Meetings should be the exception

Conclusion

Bring Back RSS for Operational Security

Bring Back RSS for Operational Security

RSS was built for exactly this problem

Security operations need boring technology

It is simple

It is machine-readable

It is decentralized

It is automatable

It is auditable

Analyst fatigue is real, and RSS helps reduce it

RSS is already useful in vulnerability management

RSS is also a strong fit for threat intelligence collection

RSS works well as an operational building block

Feed -> filter -> dashboard

Feed -> transform -> alert

Feed -> enrich -> MISP

Feed -> merge -> publish

Feed -> archive -> search

We should stop confusing “old” with “obsolete”