Jenkins looks old until you look at the release tape. ToolVitals sees 12 release events in 30 days, 20 GitHub releases in 90 days, a 100 health score, a 100 shipping score, and a 94 ToolVitals score. For a CI server with 25,258 GitHub stars, that is not nostalgia. That is active infrastructure maintenance.

The interesting signal is not that Jenkins is chasing a new category. It is that the project is still grinding through the kind of work mature CI systems need: runtime upgrades, installer trust, plugin security, UI polish, and weekly release hygiene.

The official site still positions Jenkins as the leading open source automation server, with hundreds of plugins for building, deploying, and automating projects. The GitHub repo describes it plainly as the Jenkins automation server. That matches the ToolVitals picture: this is not a pivot story. It is a continuity story.

The recent work is boring in the right way

The May 5 Jenkins 2.563 weekly release was not a flashy launch. It included UI and Manage Jenkins System page refinements, bundled updates for script-security and matrix-auth, and bug fixes around parameter dialog overflow and old data monitoring. That is exactly the maintenance surface you expect from an automation server that sits inside production delivery pipelines.

The April 30 Secret Guard Plugin post points in the same direction. Jenkins is addressing a plain operational failure mode: secrets pasted into job fields, config.xml, inline Pipeline blocks, parameter defaults, environment variables, and shell commands. The plugin is intentionally narrow, with audit, warn, and block modes, which makes it easier to adopt without turning CI governance into a giant policy project.

The April 29 Windows installer signing change is another mature-project signal. Jenkins moved MSI signing to Microsoft Artifact Signing Service, signed by LF Open Source, LLC, beginning with weekly 2.562, with the same change planned for LTS 2.555.2. That is not feature work. It is trust plumbing, and trust plumbing matters when administrators install automation software on Windows hosts.

Java 21 says more than the release count

The strongest recent public post is the Java 17 to Java 21 upgrade write-up. In that author’s Jenkins environment, memory usage moved from a monthly mean of 33 to 34 GB down to 28 GB after the JVM upgrade, without an application-level code change. That is a sourced case study, not a universal promise, but it tells you what Jenkins contributors are optimizing for: operational cost and long-running server behavior.

That matters because Jenkins is not competing only on new syntax or dashboard polish. It competes on whether teams can keep old and new delivery flows running without baby-sitting the CI controller every week. ToolVitals cannot prove your Jenkins instance will see the same memory result, but the public work shows active attention to runtime efficiency.

The GSoC 2026 post adds a community angle. Jenkins received 5 Google Summer of Code slots, including AI chatbot work, documentation retrieval, Outlook SMTP with OAuth, plugin modernization visualization, and website success stories. I would not overread that as product strategy. I would read it as contributor pipeline maintenance, which is still valuable for a project this old.

What ToolVitals cannot infer

ToolVitals can see public signals: stars, release events, GitHub releases, website availability, SSL, and scoring inputs. For Jenkins, those public signals are strong: 12 release events in 30 days, 20 GitHub releases in 90 days, 25,258 stars, and perfect health and shipping scores.

ToolVitals cannot see code quality inside every change. It cannot measure plugin compatibility across your specific estate. It cannot tell whether Jenkins is easier to operate than your current CI system, whether users are happy, whether enterprise adoption is growing, or whether a plugin you depend on is healthy. The data says Jenkins is alive and shipping. It does not say every Jenkins deployment is pleasant.

Data confidence is 83, so the story is strong but not complete. GitHub commits in the last 30 days and active contributor counts are not present in this payload. That means release velocity is the cleaner signal than commit velocity here.

The nearby comparisons are sharper than they look

Jenkins and Pulumi are almost tied on the surface. Jenkins has a 211.6 hot score, 25,258 stars, a 100 shipping score, and 12 release events in 30 days. Pulumi has the same 211.6 hot score, 25,165 stars, a 100 shipping score, and 16 release events in 30 days. The difference is not raw vitality. It is category shape: Pulumi is infrastructure as code, Jenkins is automation server infrastructure that many teams already have embedded.

ProxmoxVE Scripts is hotter on release frequency, with 19 release events in 30 days and 27,963 stars, but its hot score is 206.5, below Jenkins at 211.6. n8n is in another velocity band, with 49 release events in 30 days and 187,248 stars. That does not make Jenkins slow. It makes Jenkins a mature DevOps project shipping at a steady, production-oriented cadence rather than a hypergrowth automation app cadence.

Recommendation

If your team already runs Jenkins, do not treat it as abandonware. Evaluate the current weekly or LTS path, test Java 21 in a representative controller, review the Windows installer signing change if you deploy on Windows, and look at Secret Guard if hardcoded Pipeline secrets are a recurring risk.

If your team is choosing CI from scratch, Jenkins is still credible when plugin breadth, self-hosting, and long-lived automation workflows matter more than having the newest hosted CI experience. If you want managed convenience first, compare it against newer CI platforms. If you need an open source automation server that is still shipping maintenance work in 2026, Jenkins deserves a serious evaluation.

Sources