Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Event
GitHub Logo

Building Sustainable Open Source: The Harper Story

Discover how Harper successfully transitioned to a sustainable commercial open source platform. Ethan Arrowood details their split core licensing strategy, engineering velocity, and practical framework for building true community trust.
Event

Building Sustainable Open Source: The Harper Story

Ethan Arrowood
Head of Open Source
at Harper
June 9, 2026
Ethan Arrowood
Head of Open Source
at Harper
June 9, 2026
Ethan Arrowood
Head of Open Source
at Harper
June 9, 2026
June 9, 2026
Discover how Harper successfully transitioned to a sustainable commercial open source platform. Ethan Arrowood details their split core licensing strategy, engineering velocity, and practical framework for building true community trust.
Ethan Arrowood
Head of Open Source

Transitioning an established, closed-source company into a thriving open-source ecosystem is no small feat. In his recent talk at the Linux Foundation, Ethan Arrowood, Head of Open Source Engineering at Harper, detailed exactly how Harper made this leap with the launch of Harper v5. Driven by the core pillars of business viability and community trust, Harper’s journey provides a practical blueprint for sustainable commercial open source.

Here are the three major engineering and strategic takeaways from the Harper story:

1. The Split-Core Licensing Strategy

To successfully balance corporate sustainability with open-source values, Harper adopted a split-core distribution model:

  • Harper Core: The fully featured, production-ready core platform is entirely open source under the permissive Apache 2.0 license.
  • Harper Pro: Additional enterprise-scale features (such as replication and certificate management) are source-available under the Elastic License v2 (ELv2).
  • Harper Fabric: A fully managed SaaS hosting platform that drives company revenue and funds development of the open core.

2. Prioritizing Engineering Velocity

Splitting a codebase while supporting legacy enterprise clients can severely disrupt a team. Harper overcame this by leaning into rock-solid engineering fundamentals: stabilizing builds and tests immediately, avoiding massive simultaneous refactors, and utilizing Git to cleanly cherry-pick fixes across distinct repositories.

3. Cultivating Proactive Community Trust

True open source requires active engagement, not just making source code viewable. Harper established transparent communication boundaries, utilizing Discord for chat and GitHub Discussions for technical RFCs. They also implemented a strict human-in-the-loop contribution policy, prioritizing human creativity over fully automated AI submissions while explicitly declaring which repositories accept external contributions.

Sustaining the Foundation

A key element of Harper's philosophy is actively giving back to the open-source projects they rely on daily, including the OpenJS Foundation, Node.js, and WinterTC. Neglecting the foundational layer of the open-source ecosystem introduces major operational risks to any business built upon it.

Transitioning an established, closed-source company into a thriving open-source ecosystem is no small feat. In his recent talk at the Linux Foundation, Ethan Arrowood, Head of Open Source Engineering at Harper, detailed exactly how Harper made this leap with the launch of Harper v5. Driven by the core pillars of business viability and community trust, Harper’s journey provides a practical blueprint for sustainable commercial open source.

Here are the three major engineering and strategic takeaways from the Harper story:

1. The Split-Core Licensing Strategy

To successfully balance corporate sustainability with open-source values, Harper adopted a split-core distribution model:

  • Harper Core: The fully featured, production-ready core platform is entirely open source under the permissive Apache 2.0 license.
  • Harper Pro: Additional enterprise-scale features (such as replication and certificate management) are source-available under the Elastic License v2 (ELv2).
  • Harper Fabric: A fully managed SaaS hosting platform that drives company revenue and funds development of the open core.

2. Prioritizing Engineering Velocity

Splitting a codebase while supporting legacy enterprise clients can severely disrupt a team. Harper overcame this by leaning into rock-solid engineering fundamentals: stabilizing builds and tests immediately, avoiding massive simultaneous refactors, and utilizing Git to cleanly cherry-pick fixes across distinct repositories.

3. Cultivating Proactive Community Trust

True open source requires active engagement, not just making source code viewable. Harper established transparent communication boundaries, utilizing Discord for chat and GitHub Discussions for technical RFCs. They also implemented a strict human-in-the-loop contribution policy, prioritizing human creativity over fully automated AI submissions while explicitly declaring which repositories accept external contributions.

Sustaining the Foundation

A key element of Harper's philosophy is actively giving back to the open-source projects they rely on daily, including the OpenJS Foundation, Node.js, and WinterTC. Neglecting the foundational layer of the open-source ecosystem introduces major operational risks to any business built upon it.

Discover how Harper successfully transitioned to a sustainable commercial open source platform. Ethan Arrowood details their split core licensing strategy, engineering velocity, and practical framework for building true community trust.

Download

White arrow pointing right
Discover how Harper successfully transitioned to a sustainable commercial open source platform. Ethan Arrowood details their split core licensing strategy, engineering velocity, and practical framework for building true community trust.

Download

White arrow pointing right
Discover how Harper successfully transitioned to a sustainable commercial open source platform. Ethan Arrowood details their split core licensing strategy, engineering velocity, and practical framework for building true community trust.

Download

White arrow pointing right

Explore Recent Resources

Comparison
GitHub Logo

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Cache
Comparison
End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Comparison

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Aleks Haugom
Jun 2026
Comparison

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Aleks Haugom
Comparison

Kafka-Centered Stacks vs. a Single Harper Cluster: Where Real-Time Latency Actually Comes From

End-to-end latency in real-time pipelines comes from coordination across systems, not from any single component. Four common workloads, tested two ways, show where multi-hop architectures compound delays and where collapsing storage, messaging, and compute into one runtime changes the math.
Aleks Haugom
Tutorial
GitHub Logo

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Cache
Tutorial
Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Person with very short blonde hair wearing a light gray button‑up shirt, standing with arms crossed and smiling outdoors with foliage behind.
Kris Zyp
SVP of Engineering
Tutorial

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Kris Zyp
Jun 2026
Tutorial

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Kris Zyp
Tutorial

Your API cache is secretly a database

Most teams treat a cache as a black box: URL-keyed blobs with a TTL, useful for speed and nothing else. In Harper, cached data lands in a real table inside the same query engine. That means filtering, joining, real-time subscriptions, and vector search all work against it.
Kris Zyp
Tutorial
GitHub Logo

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
JavaScript
Tutorial
Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Person with very short blonde hair wearing a light gray button‑up shirt, standing with arms crossed and smiling outdoors with foliage behind.
Kris Zyp
SVP of Engineering
Tutorial

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Kris Zyp
Jun 2026
Tutorial

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Kris Zyp
Tutorial

Introducing Structon: Random-Access Binary Encoding for JavaScript

Deserializing entire records to read one field is a bottleneck at scale. Structon stores objects in a binary format where any field is reachable by byte offset, with lazy getters that never allocate until you access a property. It's the encoding Harper has used internally for years, now a standalone package.
Kris Zyp