From Apache User to PMC Chair: My 20+ Year Open Source Journey

Over the last few weeks, a lot of people have reached out to congratulate me on Apache Iggy graduating as an Apache Top-Level Project and on becoming the project’s PMC Chair. A few friends and engineers also asked me about my open-source journey and how I got involved with Apache.

It made me look back and realize how much open source has shaped my career and, in some ways, my life.

I started like most engineers do: as a user trying to solve a problem. Over the years, that turned into contributing, writing books about open-source technologies, building large-scale infrastructure around them, becoming an Apache committer, writing the proposal that brought Iggy into the Apache Incubator, helping the project through incubation and graduation, and now having the privilege of serving as Apache Iggy’s PMC Chair.

There was never really a plan behind any of this. I thought this would be a good time to write down some of the journey, both to celebrate the milestone and hopefully encourage engineers who are earlier in their own open-source journey.

It started with search

My introduction to open source came in the mid 2000s through search, information retrieval, and ETL pipelines.

I spent a lot of time working with Apache Camel, Lucene, Solr, and Tika initially because I needed them to build search applications. Like most developers getting into an open-source project, I learned by reading documentation, mailing lists, and source code. When something didn’t work, I would dig deeper.

Over time, I started participating more in the ecosystem. I became deeply involved with Apache Solr and eventually co-authored Apache Solr Enterprise Search Server.

Writing a technical book was an interesting form of contribution in itself. When you’re solving your own engineering problem, you can focus on the parts of the system that matter to you. When you’re explaining that system to thousands of other developers, you have to understand it differently: how it works, why it works that way, where it breaks down, and how other people should think about using it.

Search also became a big part of my professional career.

During the first decade of my career, I co-founded and led engineering at multiple SaaS startups, including a cutting-edge legal search engine. I then joined Comcast Labs to work on the search infrastructure powering X1, followed by almost seven years at Apple scaling search, personalization, data, ML and voice assistant infrastructure. Most recently at Dialpad, as an SVP Engineering, I focused on large-scale communications, cloud, data, and AI systems.

These were very different environments, but open source was always somewhere in the stack.

Working with open-source infrastructure in large production environments also changed how I thought about technology. Performance and benchmarks are important, but once you’re responsible for running these systems, you develop a healthy respect for predictable latency, failure recovery, upgrades, backward compatibility, observability, infrastructure cost, and operational simplicity.

A lot of those experiences eventually contributed to another book I co-authored, O’Reilly’s Reliable Machine Learning. Much of that book came from lessons we had learned trying to make ML systems actually work reliably in production.

Open source also changed my life

There is another part of this journey that I don’t talk about very often.

My technical work, publications, and contributions to the broader engineering community became an important part of my EB-1A extraordinary ability petition, through which I received my U.S. green card in 2015. I eventually became a U.S. citizen in 2022.

I mention this because younger engineers sometimes ask what they really get from spending their time contributing to open source. When I started, I certainly wasn’t thinking about immigration, writing books, becoming an Apache committer, or starting an open-source infrastructure company. I was contributing because I enjoyed the technology, wanted to understand it better, and wanted to help.

Looking back, that work opened doors I couldn’t have anticipated.

By then, I had spent much of my career building infrastructure from the ground up and operating it at scale. What I hadn’t done before was help build an open-source infrastructure project and its community from the ground up — where the technology, contributors, governance, and eventually the project itself needed to grow beyond the people and company that started it.

Then I met Piotr Gankiewicz.

Shared obsession with efficient infrastructure

Piotr started Iggy and deserves the credit for its original technical vision and implementation.

He was questioning some fairly fundamental assumptions about message streaming systems. If you were designing a streaming engine today, would you make the same architectural choices as systems designed one or two decades ago? What could you do differently with Rust, modern Linux I/O, thread-per-core architectures, and today’s hardware?

This was also an area I had been deeply passionate about throughout my career. I’ve always been a little obsessed with low latency, predictable performance, and getting significantly more out of infrastructure with less. Years of building and operating large-scale search, data, and distributed systems had only reinforced those instincts.

That shared obsession is a big part of what brought Piotr and me together.

We weren’t interested in optimizing only for headline throughput numbers. We cared about predictable ultra-low tail latency, efficiency, a much smaller infrastructure footprint, and developer experience. Iggy gave us an opportunity to rethink some of these things from the ground up rather than inherit assumptions from an earlier generation of streaming infrastructure.

The more we worked together, the more I felt there was an opportunity to build something important here — not just a fast streaming engine, but infrastructure that developers and companies could eventually trust for critical workloads.

The technology was one part of that. The other part was building an open-source community around it.

A technically strong GitHub project and an enduring open-source project aren’t necessarily the same thing. We wanted Iggy to develop a community and governance model that could grow beyond Piotr, me, and LaserData.

That discussion eventually led us to the Apache Software Foundation.

Taking Iggy to Apache

I wrote the original proposal to bring Iggy into the Apache Incubator. Having spent years building with Apache projects, it was a special experience to now help bring one into Apache. It also taught me a different side of open source — community governance, open decision-making, and what it really means to build a project that can grow beyond its founders and any one company.

Iggy entered the Apache Incubator in early 2025 and graduated as an Apache Top-Level Project in August 2026. Following graduation, I was asked to serve as Apache Iggy’s PMC Chair.

Going from an Apache user early in my career to helping bring a project into Apache and now chairing its PMC is a pretty special full-circle moment.And, one of the best signs of progress wasn’t any particular feature. It was seeing more people take ownership of Iggy.

We shared more about Iggy’s Apache journey and the many people who made it possible in the Apache Iggy TLP graduation post.

What I would tell someone starting today

A few people who reached out asked how someone actually becomes an open-source contributor or committer.

My experience is that there isn’t a formula, and you definitely don’t need to begin by writing a major piece of code.

Fix documentation that confused you. Reproduce a bug and provide enough information for someone else to fix it. Add a missing test. Answer a question because you recently figured out the answer yourself. Review code in an area you understand. Build an SDK or integration you need. Participate in technical discussions.

Most importantly, keep showing up.

Technical contributions matter, but healthy open-source communities need much more than code. They need people who write, review, test, document, mentor, organize, and help other contributors succeed.

My own progression from user to contributor, author, committer, and eventually PMC Chair happened gradually. There wasn’t a career plan behind it. I kept working on problems I found interesting and contributing where I thought I could be useful.

How this connects to LaserData

Looking back, this journey also explains a lot about why I’m building LaserData today. I didn’t look at a market map one day and decide that open-source infrastructure was an attractive startup category.

I’ve spent most of my career on the other side of the table: as the engineer evaluating infrastructure, the architect designing and building it, or the engineering leader deciding whether a technology was mature enough to bet a product on.

Now Piotr, our team, and I are building from the other side. Apache Iggy is the open-source foundation and belongs to its community. LaserData has a different job. We’re building the enterprise platform around that foundation for powering critical real-time and agentic data infrastructure.

We’re also thinking a lot about where this infrastructure goes next.

AI agents create and consume events, maintain state and context, coordinate with other systems, fail, retry, and need to recover. Some of these look like new AI infrastructure problems, but many are distributed-systems problems infrastructure engineers have been dealing with for decades.

The applications and abstractions keep changing. A lot of the fundamental infrastructure problems don’t. That intersection between real-time streaming, distributed systems, and AI is where we’re spending much of our time at LaserData.

In hindsight, the path from search and open source to Apache Iggy and LaserData makes a lot more sense now than it did while I was going through it. But it definitely wasn’t planned.

Looking back, and forward

When I started using Apache projects in the mid 2000s, I was mostly trying to figure out how to build better search and personalization systems. I wasn’t thinking about eventually writing books, building infrastructure at companies like Comcast and Apple, helping bring a new project into Apache, or becoming the PMC Chair of one.

That’s why this milestone means a lot to me.

I’m grateful to Piotr for creating Iggy and for everything he continues to put into the project; to our PMC members, committers, and contributors; to our Apache mentors and the broader ASF community; and to everyone at LaserData helping us build around this ecosystem.

I’m also grateful to the many open-source maintainers whose software I’ve used throughout my career. Most of them will probably never know how many products, careers, and companies were made possible by something they decided to build and share.

There is still a lot of work ahead for Apache Iggy and LaserData. In many ways, we’re just getting started.

For anyone early in their own open-source journey who happens to read this, don’t worry too much about becoming a committer or maintainer. Find a project you genuinely care about. Start helping. Learn from the people around you and keep contributing.

You might be surprised where it takes you.