There’s a reason early diagnosis gets so much airtime in healthcare — it works. Catching a condition early, whether it's an infection or something more chronic, can significantly shift patient outcomes. 

One area where early diagnosis matters is infectious disease. Being able to quickly and accurately tell the difference between a viral and bacterial infection is essential. Take otitis media in kids: [diagnostic error rates](https://otonexus.com/importance-accurate-detection-otitis-media) in differentiating viral from bacterial otitis media average 50% with traditional tools. 85% of patients get antibiotics, while only 15-20% truly need them. That’s not just overkill – antibiotic resistance becomes the next ‘cybersecurity breach’ of public health. No wonder the CDC flags it as one of the most pressing global health threats. 

So, how do we fix that? If we get the diagnosis right early on, we don’t just save money on meds — we dodge side effects and help preserve antibiotic efficacy long-term. 

Edge computing offers a path forward. Instead of sending every signal to a central server and waiting on round-trip latency, we bring the compute to the data. On-device data processing can handle noisy environments and intermittent connectivity. And if we’re being honest, it’s what separates guessing from evidence-based diagnosis. 

## What is Edge Data Processing? 

Edge data processing, aka edge computing, is about moving computation closer to the source of data generation. Unlike traditional cloud computing, where data has to be transmitted to centralized servers for processing, edge computing places processing tasks on local devices, micro data centers, or even sensors themselves. This local-first approach is a practical necessity in healthcare, where low latency, bandwidth conservation, and data privacy are non-negotiable. 

Compared to cloud-based systems, edge processing dramatically reduces the time between signal acquisition and actionable insight. It also offers advantages in maintaining patient confidentiality, keeping sensitive health information at the edge unless absolutely necessary to transmit. 

## Edge Computing Implementation Challenges in Medical Devices 

Implementing edge data processing in medical devices isn’t just a matter of choosing the right microcontroller. It involves navigating a minefield of design trade-offs, engineering constraints, and clinical usability requirements. 

A meditech company, OtoNexus, partnered with us to transition their handheld ultrasound device from an early prototype to a reliable clinical tool. The Novoscope aimed to improve the diagnosis of middle ear infections and reduce unnecessary antibiotic use. Our job was to turn that PoC into a production-ready tool that is robust enough to process diagnostic data directly on the device. 

During our [collaboration with OtoNexus](https://www.janeasystems.com/client-success/otonexus), Janea Systems team encountered 5 common edge computing implementation challenges. 

#### **Challenge #1: Data Collection and Handling** 

Edge devices need to efficiently handle data ingress and egress despite limited processing power, memory, and connectivity. When the data in question is protected medical information, the bar is even higher. Manual entry opens the door to human error, while transmitting patient information without proper safeguards risks violates HIPAA. 

**Solution:** We implemented QR code encoding and decoding for patient data collection and retrieval. Our engineers also integrated EMR for loading patient data from a QR code. All sensitive information is processed locally and transmitted using encrypted channels aligned with HIPAA compliance requirements. 

#### **Challenge #2: On-Device Data Analysis** 

Processing diagnostic signals directly on the device is one of the core promises of edge computing, but it's also among the hardest to get right. The algorithms must be clinically accurate and the implementation must fit within the device's resource envelope. In the case of Novoscope, this meant transforming research-grade code into embedded-grade production logic. 

**Solution:** We built a custom script that converts Python algorithms into optimized C++ code. This way, the device runs diagnostic logic without external dependencies. The generated code was validated through unit and integration testing against OtoNexus research benchmarks to ensure clinical accuracy. 

#### **Challenge #3: Power Management** 

Edge computing can burn through power fast. Every background process, every signal analysis routine adds to the device’s energy footprint. In a tool like the Novoscope, thermal output also becomes a limiting factor. 

**Solution:** We implemented power management protocols that extended battery life and transitioned the device between active, standby, and charging states. Our engineers added dynamic power controls based on thermal readings, optimizing energy use and extending device uptime. 

#### **Challenge #4: Network Configuration** 

Expecting clinicians to configure network settings via terminal commands or desktop apps is unrealistic. They need tools that work out of the box without a learning curve and IT support. 

**Solution:** We created a captive portal that turns the device into a temporary access point. Clinicians use their phones to configure network settings through an HTML interface, with feedback shown on the device GUI. Additionally, users can enable and disable Wi-Fi both on the GUI and low-level sides. 

#### **Challenge #5: Video Recording & Playback Support** 

Visual documentation lets clinicians review and compare measurements over time, making early detection more evidence-based. Capturing video during a diagnostic session? Tricky, but doable. But playing those videos back on the device is a whole different beast. 

**Solution:** We implemented on-device video capture and playback support tightly integrated with the diagnostic workflow. Videos can be reviewed directly on the device or transferred to the cloud for remote access and further analysis. The feature was optimized for minimal resource impact through efficient buffering and storage management. 

#### **Challenge #6: Resonant Frequency Detection** 

To ensure accurate signal acquisition, the device needs to operate at its optimal resonant frequency. That frequency isn’t fixed — it can shift slightly depending on hardware variation or environmental conditions. Detecting it automatically, in real time, and on a compact embedded system added complexity across the board. 

**Solution:** We introduced a new diagnostic test state where the device is stimulated with a test pulse and applies FFT to detect resonant frequency and amplitude. This wasn’t just a backend tweak — it was implemented end-to-end: from low-level signal handling all the way up to the GUI. And because precision matters, we rigorously tested the feature against reference data from the OtoNexus research team. 

#### **Challenge #7: Low-Level Error Control** 

Hardware issues don’t always announce themselves with flashing lights — sometimes it’s a subtle glitch or a silent failure deep in the stack. In a clinical tool, those moments can erode user trust fast. The challenge was to detect and report driver or component malfunctions without disrupting the diagnostic process. 

**Solution:** We implemented low-level monitoring that continuously checks for hardware and driver anomalies. If something fails, the system surfaces it immediately through the GUI with an error message. 

## Infrastructure Behind Edge Data Processing 

Behind the scenes, we ramped up a testing and automation framework to support the fast-moving feature set. Functional and unit tests ran continuously, backed by a CI pipeline that enforced code quality thresholds and flagged regressions early. We integrated coverage tools and enabled automated checks before merges — because in embedded systems, catching one subtle bug early is worth a hundred fixes post-deployment. Even complex debugging across the full suite became manageable with the layered structure we put in place. 

Edge projects are full of these sharp corners, but with the right tooling and clear communication with clinical stakeholders, they’re also incredibly rewarding to ship. 

Janea Systems team specializes in navigating those sharp corners. With over two decades of experience in edge computing and embedded systems, we’re able to transform PoC into production-grade tools that meet clinical requirements. Whether it’s patient data handling, edge data processing, or operating within power constaints – our engineers are well-versed in solving complex technical challenges. 

Have an edge computing project in mind? Get in touch — we’re ready to help.  

## Frequently Asked Questions (FAQ) 

#### **What are the top edge computing applications in healthcare?** 

Edge computing applications in healthcare include real-time diagnostics, remote patient monitoring, wearable biosensors, handheld ultrasound devices, and smart infusion pumps. 

#### **How does edge data processing improve clinical data management?** 

Edge data processing allows clinical data to be captured, analyzed, and acted upon at the point of care. This improves clinical data management by enabling immediate feedback, reducing transcription errors, and ensuring that healthcare data processing complies with privacy standards like HIPAA. 

#### **What is the lifecycle of data handling in edge-based medical systems?** 

The life cycle of data handling includes data collection and handling, local processing, secure transmission (if needed), and clinical feedback.

Discover how our engineers implemented edge computing in healthcare, from healthcare data processing at the edge to power management.

Edge Computing for Healthcare: Challenges & Solutions

Edge Computing for Healthcare: Implementation Challenges & Solutions  

Earlier this month, the [Data + AI Summit 2025](https://www.databricks.com/dataaisummit), hosted by Databricks, took place at the Moscone Center in San Francisco. As one of the largest gatherings of data professionals, engineers, AI researchers, and enterprise leaders, the summit offered a comprehensive look into the evolving data and AI ecosystem.

The central theme of this year was bringing data and AI closer together, not just in tooling but in practice. Our colleague, [Bill Sanders](https://www.linkedin.com/in/billsanders4/), was on-site to take in the keynotes, breakout sessions, and hallway conversations that make this event as much about people as it is about platforms. Here’s what stood out.

## Evolution of Databricks AI Summit

Databricks co-founder and CEO Ali Ghodsi [opened the summit](https://youtu.be/PFVJL7_W4dI?si=WoeeSRXObXHJLRxD) by tracing the conference’s decade-long journey — a story of exponential growth and a shift in industry focus from data wrangling to intelligent automation.

*   **10 Years Ago.** The conference (then Spark Summit) had over 3,000 attendees. The primary focus was data engineering and simplifying big data, with the recent release of Apache Spark 1.0.
*   **3 Years Ago.** Attendance grew to over 5,000. The focus shifted more towards Artificial Intelligence, leading to the conference name change to Spark + AI Summit. Ghodsi recalled live-coding with TensorFlow and generative AI at that time, expanding their focus to both data and AI.
*   **Today.** The conference now hosts over 22,000 in-person attendees, making it a "citywide conference" and the largest data and AI conference globally. It also has 65,000 worldwide viewers from 150 countries. The program includes 700 sessions and trainings, over 350 customer presentations, and 180 exhibitors.

While the event may now draw tens of thousands, its foundations remain deeply rooted in one principle — openness. And that’s where the conversation naturally turned next.

## The Mission to Democratize Data & AI

Ali Ghodsi underscored what has always been at the core of Databricks’ growth: a deep commitment to open source and a mission to democratize data and AI.

Databricks has contributed to and supported some of the most widely adopted tools in the modern data stack:

*   **Apache Spark** — with more than 2 billion downloads, Spark remains the foundation for distributed data processing at scale.  
*   **Delta Lake** — with over 1 billion downloads, it introduced ACID transactions to data lakes, setting the groundwork for the lakehouse architecture.  
*   **Apache Iceberg** — with 360+ million downloads, and now fully supported by Databricks since its adoption last year, enhancing open table formats for performance and interoperability.  
*   **MLflow** — with over 300 million downloads, MLflow powers much of the experimentation and reproducibility in MLOps and generative AI development today.

Beyond the numbers, Ghodsi reinforced the broader goal: making advanced data and AI capabilities available to as many people and organizations as possible, regardless of their infrastructure, cloud provider, or technical maturity.

This vision isn’t pursued in isolation. Ghodsi acknowledged the critical role of key partners in realizing it: AWS, Google Cloud, Microsoft Azure, Accenture, Deloitte, and the growing network of technology and marketplace partners.

He also emphasized the importance of data providers available through the Databricks Marketplace, making Delta Sharing more seamless, enabling businesses to collaborate over live data.

And at the center of it all: 15,000 customers using Databricks to power real-world outcomes. As Ghodsi put it, “That's the real impact. That's where the interesting things are happening.”

![photo_2025-06-19_15-50-35.jpg](https://janea-minio.apps-us2.janeasystems.com/public/photo_2025_06_19_15_50_35_0ad68666c0.jpg)

## Barriers to Data and AI Adoption

While the momentum around data and AI has never been greater, many organizations — especially those with long histories and legacy systems — struggle with AI adoption. The excitement is there. The potential is clear. But the path forward remains blocked by deep architectural and organizational complexity.

> _For data and analytics leaders, this moment presents an opportunity to re-evaluate architectural choices, explore new modes of user engagement, and consider emerging frameworks for modernization and AI adoption._
> 
> _Bill Sanders_

Here’s the most common scenario Databricks encounters across industries: an ecosystem of fragmented, overlapping technologies that have grown organically over time, often without a cohesive plan.

Most enterprises deal with:

*   A mix of data warehouses, both on-prem and cloud-based
*   Massive data lakes filled with unstructured or semi-structured data
*   Custom-built real-time streaming systems
*   Bespoke ETL pipelines tied to legacy infrastructure
*   Multiple generations of BI tools, some in use for decades
*   New layers of data science platforms, ML models, and generative AI experiments added on top

Each component may solve a specific problem. But together, they form a brittle, disjointed architecture — difficult to evolve and expensive to maintain. This results in:

*   Operational drag — projects slow down, innovation stalls.
*   Runaway costs — with overlapping tools and redundant data movement.
*   Vendor lock-in — often invisible until it’s too late.

Ghodsi argued that the real problem lies beneath the surface — in the **metadata**.

Each system not only stores data but also metadata, access controls, security models, and governance logic. Enterprises don’t just manage data silos — they manage policy silos. This makes end-to-end visibility, governance, and control nearly impossible. Without a unified approach to data and metadata, AI becomes harder to operationalize — and even harder to trust.

These challenges mirror what we observe across many of our client engagements, where disconnected data pipelines, legacy BI tooling, and fragmented governance delay innovation. In our experience, optimizing data engineering tasks can result in [up to 24% faster ML workflows](https://www.janeasystems.com/blog/up-to-24-percent-faster-ai-in-machine-learning-data-devops).

## The Lakehouse and Unified Governance

In response to the architectural and operational fragmentation, Databricks continues to advance a solution that is both technically rigorous and strategically bold: the Lakehouse.

It’s a concept introduced by Databricks five years ago — initially met with skepticism, particularly from traditional data warehousing vendors and cloud hyperscalers. But today, the model has gained widespread traction. And in Ghodsi’s view, it’s not just a compelling architecture — it’s a pragmatic path forward.

### Step 1: Centralizing Data with Open Formats

The first move is deceptively simple: centralize data using open formats.

That means getting data out of proprietary systems and into affordable, open cloud object storage, such as Amazon S3, Azure Data Lake Storage (ADLS), or Google Cloud Storage (GCS), using non-proprietary table formats like Delta Lake or Apache Iceberg.

The goal is not just interoperability. It’s control. The Lakehouse gives organizations full ownership of their data, while preserving performance and structure that bridges the historical gap between lakes and warehouses.

### Step 2: Unified Governance

But open storage alone isn’t enough. The real breakthrough comes with governance — and more specifically, a unified governance layer that spans the entire data estate.

**Key Idea 1: Govern All Data Assets**

Modern governance must extend beyond databases. That includes:

*   Unstructured data (images, text, logs)
*   AI and ML models
*   Dashboards — which Ghodsi rightly pointed out are one of the easiest ways to leak sensitive information

The vision is **lineage-aware governance**: track and secure data across its full lifecycle in one consistent framework.

**Key Idea 2: Unified Capabilities on Top of Data**

True governance isn’t just about access permissions. It’s about enabling clarity, coordination, and control across teams. The Unity Catalog, Databricks’ governance layer, is designed to support:

*   Discovery – so teams can easily find relevant datasets
*   Collaboration – by eliminating redundant work and resolving inconsistent metrics
*   Lineage Tracking – to understand how data moves and transforms
*   Business Semantics – defining authoritative data (e.g., what constitutes “revenue”)
*   Cost Management – centralized visibility into resource usage
*   Data Quality – surfacing issues early and systematically

While many solutions in the market (like Polaris) focus narrowly on access control for structured data, Databricks is positioning Unity Catalog as a governance platform for the full data + AI lifecycle.

### AI Inside the Lakehouse

Databricks extends the Lakehouse into a Data Intelligence Platform, where AI is embedded throughout to make data and insights accessible to everyone. The vision focuses on two goals:

1.  Democratizing Data Access – enabling users to query and understand data using natural language with two tools: Genie and Assistant.  
2.  Democratizing AI – empowering businesses to build their own intelligent agents that reason over proprietary data with Mosaic AI Agent Framework and classic ML & Generative AI.

By combining open data infrastructure with intelligent automation, Databricks aims to simplify the user experience and prepare organizations for the next wave of AI-native workflows. We've explored this in depth in our experiment on [AI in frontend and backend engineering](https://www.janeasystems.com/blog/ai-in-frontend-and-backend-engineering), where AI streamlines developer velocity across the stack.

## A New Era for Enterprise Data

Chase’s Jamie Dimon from JPMorgan, one of the guest speakers, hammered home the message: “_AI isn’t the hard part — data is_.”

That message echoed throughout the Databricks Data + AI Summit 2025, where the spotlight was not on flashy AI demos, but on the groundwork required to make AI viable at scale. The AI Summit revealed a decisive shift in how enterprises approach data, moving beyond fragmented stacks and legacy dashboards toward simplified, AI-native platforms that emphasize usability, governance, and trust.

While some of the announcements will take time to translate into real-world impact, the direction is unmistakable: simplified experiences, governed access, and more intelligent consumption of data.

---

As data complexity and expectations around AI grow, data management takes a central stage. Janea Systems team brings over two decades of experience helping organizations manage and modernize their data infrastructure, from open-source platforms to enterprise-grade software.

We're proud to be one of Microsoft’s long-standing technical partners. Our engineering team co-developed mission-critical MSFT projects, including:

*   [Azure Maps custom styling](https://www.janeasystems.com/client-success/azure-maps-custom-styling)
*   [Azure Maps indoor styling](https://www.janeasystems.com/client-success/azure-maps-indoor-styling)
*   [PyTorch on Windows](https://www.janeasystems.com/client-success/pytorch-for-windows)
*   [The foundations of .NET](https://www.janeasystems.com/client-success/dotnet-clr)
*   [PowerToys – an open-source productivity suite](https://www.janeasystems.com/client-success/microsoft-powertoys)

Whether you modernize pipelines or adopt AI across the SDLC, our team has the experience delivering intelligent systems that scale. We’ve explored [AI-assisted development](https://www.janeasystems.com/blog/AI-assisted-development-across-sdlc) across the software development lifecycle and now leverage our findings for our clients’ projects.

Get in touch – let's explore ways to simplify and scale your data architecture.

Discover takeaways from the Databricks Data + AI Summit 2025 and learn how enterprises rethink architecture for the AI era.

Unifying Data, Simplifying AI: Data + AI Summit 2025 Recap 

On June 23-25, open source leaders and practitioners from around the world gathered for the [Open Source Summit North America 2025](https://events.linuxfoundation.org/open-source-summit-north-america/) hosted by the Linux Foundation. The event served as a pulse check on the health of the OSS ecosystem, surfacing both urgent challenges and emerging opportunities in infrastructure, licensing, and governance.

Our Business Development Director, [Mirza Baig](https://www.linkedin.com/in/mrbaig/), was on-site, engaging with maintainers, attending technical sessions, and bringing back insights from keynotes and hallway conversations. If one theme dominated this year’s summit, it was this: open source plays a critical role in global innovation, economic growth, and digital resilience. 

> _What stood out most to me, though, were the people-focused challenges that come with that growth. Sustainability through people emerged as a key theme, highlighting maintainer burnout, the lack of leadership pipelines, and the risks of accidental stewardship in critical projects._
> 
> Mirza Baig

Here’s what we learned on the ground.

## Rethinking Open Source Economics

The first day of the summit revolved around one question: What is the economic impact of open source software? Not only how much it saves us in development time, but how deeply it powers the digital economy. Frank Nagle, a Harvard Business School professor and [newly appointed](https://www.linuxfoundation.org/press/linux-foundation-appoints-frank-nagle-as-advising-chief-economist) Advising Chief Economist for the Linux Foundation, offered an answer.

According to Nagle's 2024 research paper, "[The Value of Open Source Software,](https://www.hbs.edu/ris/Publication%20Files/24-038_51f8444f-502c-4139-8bf2-56eb4b65c58a.pdf)" if open source vanished tomorrow, companies around the globe would need to spend 3.5 times more to replace it. That adds up to a staggering $8.8 trillion in demand-side value. In other words, open source is a foundational layer of our economy.

Historically, estimates of open source value focused on the supply side — what it would cost to re-create the code. Nagle’s team puts that figure at $4.15 billion. But his study flips the script. It calculates how much companies would have to spend to build or buy alternatives if open source didn’t exist. That demand-side perspective paints a far more complete picture of our economic dependency on OSS.

*   **Ubiquity**: 96% of commercial codebases include open source components.
*   **Concentrated Creation**: Just 5% of open source developers generate 96% of that $8.8 trillion value.
*   **Productivity Gains**: Companies that contribute to open source boost their productivity twice as much as those that only use it.

The very openness that makes OSS powerful also makes it vulnerable. If everyone benefits but no one takes responsibility, the system suffers. It’s time for corporations and policymakers to step up and invest in maintaining the digital public goods they depend on. 

Janea Systems has been at the forefront of open source software development for years, helping companies like Microsoft build, scale, and maintain mission-critical OSS projects, including:

*   [PyTorch for Windows](https://www.janeasystems.com/client-success/pytorch-for-windows)
*   [Node.js](https://www.janeasystems.com/client-success/node-js-windows)
*   [Microsoft PowerToys](https://www.janeasystems.com/client-success/microsoft-powertoys)
*   [React Native for Windows](https://www.janeasystems.com/client-success/react-native) 

We help organizations contribute responsibly while capturing the full value of open collaboration:

*   Our engineers fix critical bugs in performance-sensitive environments, such as [resolving a CUDA matrix multiplication issue in PyTorch](https://www.janeasystems.com/blog/pytorch-matrix-multiplication-cuda-bug).
*   We address integration challenges, such as [MKL Sparse incompatibilities in PyTorch](https://www.janeasystems.com/blog/MKL-Sparse-PyTorch-Fix).
*   Also, we help teams modernize their infrastructure, including [porting software to ARM64 architecture](https://www.janeasystems.com/blog/porting-software-arm64).

Through contributions like these, Janea Systems continues to reinforce the OSS ecosystem with engineering expertise where it’s most needed.

## Agent2Agent (A2A): A Universal Language for AI Collaboration

Later in the summit, attention turned to the next leap in AI: getting autonomous agents to collaborate. Mike Smith from Google introduced the Agent2Agent (A2A) protocol — an open standard designed to help AI agents communicate and work together, securely and at scale.

Think of A2A as a universal language for AI. Whether built by Google, AWS, Microsoft, or anyone else, A2A gives agents a shared way to exchange information and collaborate on complex tasks. It’s the protocol equivalent of tearing down the walled gardens of AI.

And Google isn’t keeping it to itself. They [donated](https://thenewstack.io/google-donates-the-agent2agent-protocol-to-the-linux-foundation/) the A2A protocol to the Linux Foundation, ensuring open, neutral governance with over [50 companies](https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/) already on board, including major rivals of Google. 

**How A2A Works**

*   **Agent Discovery**: Every agent publishes an "Agent Card"— a JSON file that lists its skills and how to connect. This allows other agents to discover who can perform a specific task. 
*   **Standardized Communication:** A2A is built on proven web standards (HTTP, JSON-RPC, SSE), making it easy to slot into enterprise systems.
*   **Task Management:** From simple sync requests to long-running, async tasks, the protocol defines a full task lifecycle.
*   **Secure by Design**: Agents don’t have to expose internal logic, proprietary tools, or memory to collaborate. A2A keeps things private and enterprise-ready.

The vision is to lay the foundation for an interconnected world of intelligent systems. A future where AI agents function like a social network, each with its own strengths, discovering each other, and teaming up in real time. With A2A, we’re one step closer to that world.

## Confronting the Maintainer Succession Crisis

One of the most urgent and human challenges surfaced at the summit was the crisis in open source project sustainability: maintainer burnout, and the lack of a viable pipeline for succession. This issue was the subject of a compelling presentation by [Abigail Cabunoc Mayes](https://abbycabs.github.io/), who leads open source maintainer programs at GitHub.

In her talk, "Who Will Maintain the Future?" Mayes drew on her experience founding the Mozilla Open Leaders program, which mentored over 600 projects in building sustainable and community-driven practices. Today’s open source is maintained by a shrinking group of overburdened contributors, many of whom are quietly aging out or burning out.

Nearly [60%](https://dev.to/tidelift/open-source-maintenance-can-be-stressful-lonely-and-financially-unrewarding-39hb) of open source maintainers have either left or considered leaving a project. The reasons aren’t about architecture or frameworks — they’re personal: competing life demands (54%), loss of interest (51%), and burnout (44%) top the list. More than half say their work is undercompensated, and nearly the same number say it’s a major source of personal stress. For the 44% maintaining projects solo, the pressure can be intense and isolating.

Author Nadia Eghbal famously [described](https://www.briansnotes.io/book/working-in-public/) this dynamic as “free as in puppy.” A developer launches a project out of passion, but as it gains traction, maintaining it becomes an unending chore — similar to raising a large, unruly dog. The initial spark is replaced by long-term responsibility and invisible labor.

We saw the consequences play out dramatically in the 2024 XZ Utils backdoor incident. A seemingly helpful contributor exploited a solo maintainer’s isolation, eventually inserting a malicious backdoor into widely-used software. The fallout? A 66% drop in maintainer trust toward new contributors, and a deepening of the very isolation that fuels burnout.

When Linus Torvalds himself flags the aging of Linux kernel maintainers, it’s a sign that the issue cuts across all layers of the OSS stack. Zombie dependencies, loss of institutional memory, and rising security risks are already here. Outdated code becomes a liability, exposing organizations to bugs, breakage, and breaches.

For years, the technology industry has discussed the "bus factor" — the risk of a project collapsing if a key developer is hit by a bus — as a hypothetical concern. [CHAOSS](https://chaoss.community/kb/metrics-model-starter-project-health/) re-frames this as the "Contributor Absence Factor" to make it more measurable.

The risk is not **if** another XZ-like event will happen, but **when**, and in which of the thousands of under-maintained packages it will occur. This transforms the problem from a community health issue into a critical portfolio risk management issue for every Chief Technology Officer and Chief Information Security Officer.

## Implementing Open Source Succession Planning

The open source ecosystem can no longer afford to rely on the spontaneous emergence of "hero" maintainers to sustain its most critical projects. The reality is sobering: [research shows](https://www.businesswire.com/news/home/20240917030299/en/Tidelift-Study-Reveals-Paid-Open-Source-Maintainers-Do-Significantly-More-Critical-Security-and-Maintenance-Work-Than-Unpaid-Maintainers) that 85% of the most popular GitHub projects rely on a single developer for the majority of commit-related discussions. That’s a bottleneck waiting to fail.

It’s time for organizations to move from an ad-hoc culture of individual heroics to one of deliberate resilience. Structured succession planning — a common practice in enterprise settings — must be translated to the open source context. This means identifying critical roles early, assessing contributor capacity, and building a pipeline of talent to step in as stewards when needed.

An open source succession plan starts with more than just naming a backup maintainer. It means mapping out all essential project functions, including code maintenance, community engagement, documentation, security, and identifying contributors who can grow into those roles. Programs like Mozilla Open Leaders offer a blueprint: guided mentorship, clear advancement paths, and formal knowledge transfer all help transform succession from a crisis response into a healthy, proactive process.

Ultimately, the goal is to shift the narrative from burnout and bottlenecks to continuity and collaboration. That doesn’t just protect codebases, but future-proofs the ecosystem.

This is where Janea Systems' engineering expertise becomes a strategic advantage. Our teams don’t just write code, they deliver solutions to some of the toughest technical challenges in the industry. Organizations that depend on open source can no longer afford to simply consume it. They need to actively invest in keeping it healthy and sustainable.

Partnering with Janea Systems means gaining more than software development capacity. It means enlisting a team committed to the resilience and longevity of the digital infrastructure we all depend on.

**If your company depends on open source, it’s time to invest in its future.** 

Get in touch with our experts to explore how your company can strengthen its open source strategy and safeguard its digital infrastructure.

Discover what we learned at OSS Summit 2025—from the $8.8T impact of open source to maintainer burnout and the future of AI agent collaboration.

Inside Open Source Summit North America 2025

small_Frame 17 (1).jpg

thumbnail_Frame 17 (1).jpg

Frame 17 (1).jpg

Anastasiia

Content Creator

large_Janea Systems OG Image No Text.png

medium_Janea Systems OG Image No Text.png

small_Janea Systems OG Image No Text.png

thumbnail_Janea Systems OG Image No Text.png

Janea Systems OG Image No Text.png

Janea Systems is a software engineering consultancy, serving the enterprises that drive global innovation for over two decades. We help our clients build and optimize technologies used by millions of developers and billions of consumers. 

Related Blogs

Let's talk about your project

Let's talk about your project