Skip to content

[BLOG] The Opensearch Dashboards story : How to Change Everything and Break Nothing - A pragmatic modernization story #4062

New issue
New issue
Open
Open
[BLOG] The Opensearch Dashboards story : How to Change Everything and Break Nothing - A pragmatic modernization story#4062
Assignees
anirudha
Labels
New blogNew blog post
@anirudha

Description

@anirudha
anirudha
opened on Jan 26, 2026

Describe the blog post

OpenSearch Dashboards is, it’s this: a mission-critical user interface that never gets to “pause.” People use it to run businesses, investigate incidents, and make calls with real consequences. And the awkward truth of software like that is you can’t modernize it the way you renovate a vacation home. You modernize it the way you rebuild a ship while it’s crossing an ocean.

Chapter One: the ship, the sea, and the size of the map

That ocean is big. OpenSearch Dashboards sits at a little over a million lines of code, with roughly thirty-nine thousand commits behind it and hundreds of distinct humans who’ve left fingerprints on the hull. Open Hub pegs it at 1,037,045 lines of code, 39,022 commits, and 743 contributors, with a “first commit” lineage reaching back to February 2014.

That scale matters because it changes what “modernization” even means. At this size, you don’t modernize by rewriting. You modernize by continuously restoring trust: in builds, in security posture, in plugin compatibility, in release cadence, in user workflows that someone, somewhere, has built their job around.

The platform’s nervous system is extensibility. There’s a core that boots, routes, renders, and secures, and then a constellation of internal and external plugins that turn a generic dashboard shell into a use-case engine. The official developer guide puts it plainly: you bootstrap the repo, it builds “all internal packages and plugins,” and the architecture and plugin system are first-class citizens, not an afterthought.

And then there’s time. OpenSearch follows semver and ships minor releases on a release-window model that targets “approximately every eight weeks,” with release candidates generated daily once the window opens. If you’re a leader reading this, that line should jump out: a strong release cycle isn’t just a process brag. It’s the mechanism that makes modernization survivable.

Chapter Two: how Kibana became Dashboards

Before it was OpenSearch Dashboards, this story lived in the Kibana ecosystem: dashboards and visualizations as the front door to search and analytics. That lineage matters because the “age” of OpenSearch Dashboards isn’t just the day this GitHub repository appeared; it’s the day the ideas and workflows first became production muscle memory.

The fork point is now common industry lore: OpenSearch is an Apache-licensed project derived from Elasticsearch 7.10.2 and Kibana 7.10.2, and OpenSearch Dashboards is the UI half of that inheritance. Docker Hub’s official OpenSearch image description states that lineage directly. Wikipedia’s Kibana entry also captures the moment from the other side of the mirror, noting that OpenSearch released an Apache-licensed fork of Kibana after Elastic’s licensing shift.

In this repository, you can still see the early fork archaeology in small, almost tender commits; like the April 10, 2021 PR that literally updates “kibana and elasticsearch references.” It’s a tiny patch, but it’s also a flag planted: we are now steering this ship under a different banner.

Repository metadata sites peg OpenSearch Dashboards’ creation in early 2021, which matches the public fork timeline, even as the code’s deeper history stretches back years before that.

Chapter Three: the Angular years, and the security tax nobody budgets for

Modern web platforms have a dirty secret: the oldest code isn’t always the ugliest. Often it’s the most “successful,” because it survived long enough to become load-bearing.

In the Kibana era, AngularJS was a major part of that load. Even Elastic’s own issue threads from a few years ago describe “quite a few plugins relying on AngularJS,” with a list that reads like the greatest hits of a dashboard product line; dashboard, discover, timelion, monitoring, and more and a very real question: do we maintain our own Angular fork, find third-party support, or accelerate the move away?

Community discussions later made the migration pressure explicit for plugin authors: people upgrading from older Kibana versions described Angular-written plugins as a compatibility cliff, and noted that “starting from Kibana 7.10, the plugins written in Angular.js are not supported.”

That’s the product tension in one sentence: a platform can’t stay secure and modern and stay frozen in time. AngularJS hit end-of-life, and when a framework goes EOL, the security bill doesn’t stop arriving; it just starts arriving addressed to you. Analyses of AngularJS vulnerabilities call out the long-term exposure problem: CVEs don’t politely end when official support ends; they accumulate, and mitigation shifts from “update dependencies” to “build your own parachute mid-air.”

So when people describe modernization as a “feature,” they’re missing the point. Modernization is often a security strategy disguised as UI work.

Chapter Four: the herculean middle; keep the lights on, change the wiring anyway

Here’s where the story stops being history and becomes craft.

OpenSearch Dashboards isn’t just modernizing the UI; it’s modernizing the delivery system;; the stuff executives don’t see until it breaks. A million-line codebase doesn’t fall behind because the team is lazy. It falls behind because the toolchain evolves faster than a stable platform can safely ingest.

Start with the foundation: Node. A recent merged PR moves the project to Node 22.21.1. That sounds small until you’ve lived it: Node upgrades cascade into tooling, build performance, dependency graphs, CI images, developer machines, and “why does this test only fail on Tuesdays.”

Then the build system: a merged PR migrates Webpack 4 to Rspack. This is the kind of change that doesn’t win hearts on a demo day, but it wins quarters of engineering time back over a year. Faster builds don’t just make engineers happier; they make releases safer because you can iterate more, test more, and revert faster when reality disagrees.

Then the UI runtime: React 18 is on the table, with an explicit discussion of how to do it without detonating the entire plugin ecosystem. The React 18 tracking issue even calls out a “recommendation” to upgrade “without enabling StrictMode,” and quantifies the blast radius: hundreds of useEffect calls and multiple render-path replacements (ReactDOM.render to createRoot). That’s sober engineering: modernize, yes, but don’t turn your user base into a volunteer QA program.

And then the design system, where modernization becomes visible. The OUI 2.0 modernization effort frames a path to an OpenSearch-native UI library, with plans for shims and codemods to reduce migration pain. If you’ve ever tried to roll out a new component library across a sprawling plugin universe, you know why those words matter. Shims and codemods aren’t “nice to have.” They’re how you prevent a platform from fracturing into incompatible dialects.

Now the part users do feel: visualizations. The direction of travel is toward ECharts, with an active set of pull requests explicitly tagged around “echarts.” This isn’t just swapping a charting library; it’s choosing the rendering engine for the next decade of “how humans see their data.”

Somewhere in the middle of all that, the platform still has to keep its promise: compatibility. Dashboards isn’t a single app; it’s a host. It supports internal plugins, external compatible plugins, and long-lived workflows that need to keep working even as the underlying architecture gets re-plumbed.

Chapter Five: release discipline and a grown-up security posture

Modernization without governance is just motion.

OpenSearch publishes its release schedule in public, including upcoming 2026 windows; 3.5.0 opening January 27, 2026, and a cadence that keeps marching through the year. That schedule is more than community transparency; it’s operational discipline. It tells every downstream team, vendor, and operator: you can plan.

Security posture is treated the same way: explicit, public, and policy-driven. The OpenSearch maintenance policy states it follows OpenSSF best practices for patching publicly known vulnerabilities, with the requirement that actively maintained versions have no unpatched medium-or-higher vulnerabilities that have been publicly known for more than 60 days.

If you want the executive translation: this is how you reduce systemic risk in an ecosystem where dependencies, supply chain threats, and disclosure timelines don’t care about your roadmap. And it aligns with broader OpenSSF concepts like Scorecard and best-practices frameworks that exist precisely to make OSS security measurable rather than vibes-based.

Chapter Six: adoption signals : the quiet proof in the download counters

Usage is hard to measure perfectly, but distribution channels leave footprints.

On Docker Hub, the official OpenSearch Dashboards image shows 10M+ pulls, and the broader OpenSearch image family sits at 100M+ pulls. Even with all the caveats of “pulls aren’t users,” those numbers tell you something important: this stack is not a toy, and the cost of breaking changes is real money for real organizations.

On GitHub, the repository itself shows steady activity and community gravity; stars, forks, issues, pull requests, and a large commit history visible right on the project page.

Chapter Seven: AI as the accelerator, and modernization as the on-ramp

Here’s the twist ending that’s actually the beginning of the sequel.

Modernization used to be a tax: necessary, painful, and easy to postpone. AI changes the math, but only if the codebase gives AI something it can reliably work with.

Inside many teams, AI assistants are already doing meaningful work: proposing refactors, generating test scaffolds, summarizing regressions, and turning “this should be a migration script” from a two-week project into an afternoon. OpenSearch Dashboards has its own signs of this trend; recent work includes experimental AI chat and context provider plugins.

But the deeper point is cyclical: AI helps modernization, and modernization helps AI.

AI helps modernization because it thrives on repetitive patterns. When you have to touch hundreds of call sites for something like a React 18 root change, you want tools that can draft the boring parts while humans focus on the risky parts.

Modernization helps AI because it reduces entropy. A codebase on a modern Node runtime, with a faster build pipeline, with TypeScript steadily enforced, with a coherent component system, becomes more legible; not just to humans, but to AI tooling that depends on predictable structure.

And that’s the flywheel: faster builds mean tighter iteration loops; tighter loops mean smaller PRs; smaller PRs mean easier review; easier review means safer releases; safer releases mean you can modernize without fear.

Epilogue: 2026, and the work that’s still gloriously unfinished

If this were a fairy tale, the modernization would end with a ribbon-cutting: “and then the platform was modern.”

But real platforms don’t get endings. They get chapters.

The story heading into 2026 is that OpenSearch Dashboards is becoming a modern dashboarding framework in the full sense: Rspack for the build future, Node 22 for the runtime present, React 18 as the UI baseline, a next-gen design system direction that points toward shadcn-style ergonomics, and ECharts shaping the next era of visualization; while still holding the line on compatibility for legacy users who cannot afford disruption.

And if you’re reading this as a leader, that last clause is the whole point: modernization isn’t a pivot away from existing users. It’s how you keep your promise to them for the next decade; without pretending the world will stop changing.

The ship is still at sea. The crew is still swapping timbers. The horizon says 2026. And the best part is that the modernization itself is starting to compound: every upgrade makes the next upgrade less terrifying.

That’s not a finish line. That’s momentum.

Core Repository & Project

Adoption & Download Metrics

Lineage, Fork, and Licensing Context

Legacy Angular Context & Security Pressure

Modernization RFCs, Issues, and PRs (Primary Spine)

Umbrella Modernization

Runtime & Build System

React 18 Modernization

Design System & Platform Evolution

Visualization Modernization (ECharts)

Release Cadence & Governance

AI & Emerging Capabilities (Contextual)

Expected Title

[ Blog Draft ]The Opensearch Dashboards story : How to Change Everything and Break Nothing - A pragmatic modernization story

Authors Name

Anirudha Jadhav

Authors Email

anirudha@nyu.edu

Target Draft Date

2/10/2026

Blog Post Category

technical

Target Publication Date

No response

Additional Info

No response

Metadata

Metadata

Assignees

Labels

New blogNew blog post

Type

No type

Projects

OpenSearch Blog Content Calendar + Tracker

Status

In Progress

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions