I sat down with Bianca Lewis of OpenSearch at Open Source Summit India, right after the project's second OpenSearch Con in the country. Bianca Lewis is the executive director of the OpenSearch Software Foundation.

OpenSearch started life in 2021 as a fork of Elasticsearch, born out of Elastic's move away from an open source license. Five years on, I wanted to know how much of that origin story still holds, and how the project sees itself now that it's an AI data infrastructure layer with its own roadmap and its own community.

We covered a lot of ground: whether OpenSearch is still tethered to Elasticsearch in any way, why ELK Stack remains the more recognizable brand among young developers, how agentic AI fits into the platform, and an uncomfortable but necessary question about what happens when vendor-backed open source projects go proprietary.

Five years in, is OpenSearch still a fork of Elasticsearch, or has it become a product of its own? Does it still pull in any downstream changes from Elastic?

Bianca: That is a great question, and the answer, very simply, is yes, it's an independent project. It's a completely independent project now that began as a fork, as you correctly said, and in the early days the two were very, very similar. Today the focuses and the strengths have become very different, and today they are completely independent projects. I think the only commonality is that users can still use both platforms for similar kinds of use cases.

Explaining OpenSearch to the average Linux user

OpenSearch is enterprise-focused, but how would you explain it to a home labber or self-hoster who's never heard of it?

Bianca: Well, firstly, of course OpenSearch is an AI infrastructure layer for enterprises, but because it's on an open source platform, free and easy to use and adopt, people making new startups, entrepreneurs, developers, and everyone else find it very easy to get started. Download it, it's free to use, all the features are open and available, and they can join very easily a community of thousands and thousands of people to get up and running.

So it's not just enterprise-focused anymore, it's for anyone and everyone. Whoever's requirements fit it, OpenSearch is for them. I don't think it was ever built to just be for the enterprise. The startups of today are the enterprises of tomorrow.

"The startups of today are the enterprises of tomorrow."

The ELK Stack brand problem

ELK Stack is still the more recognizable brand in observability and search. How does OpenSearch compete with that brand recognition among young developers?

Bianca: There is no doubt that Elastic, Elasticsearch, and Logstash and Kibana, which make up ELK, have been around a long time, and that's obviously where the fork came from originally. I hope that after five years of OpenSearch developing as an independent and powerful project — 1.7 billion downloads later, 400 individual companies contributing, more than 3,000 contributors, and 15,000 OpenSearch stack users — the differentiation in young developers' minds is becoming clearer just from the sheer weight of numbers.

I think there are two distinguishing factors. The first is philosophy — how developers want to build their technology stacks conceptually and into the future. Elastic, who owns ELK, even though the license is now back to open source after they closed it, is still owned by Elastic and is open core. That means if a young developer wants to build on Elasticsearch and use the ELK stack, they can use the core version for free, but for any more advanced features or support they're going to have to pay and be tied into Elastic. Developers who want to build on a platform that's fully open, where you get the whole thing for free and can choose whether you want support or hosting when you're ready, have that choice with OpenSearch. It's a different philosophy.

The second layer is that the two platforms have grown along different technological paths. Every platform in this space will say "we're a millisecond faster at this," or "we support this use case better," and that's all true — no platform can honestly say it's the best at everything. But OpenSearch is really good at a lot of different use cases that unify the data layer, and because it's the only alternative that isn't just open core, it's making young developers distinguish OpenSearch, hopefully much faster than ELK or any other platform.

Observability, complexity, and cost

Observability stacks are getting heavier, more expensive, and more complicated. What is OpenSearch doing about ease of setup and cost?

Bianca: Those are two very valid questions, so let me answer them one by one.

On complexity: the advantage of proprietary vendors has always been that on day one it's easy — you buy it, it's off the shelf, it works, and you get support. With an open platform, you build it on day one, and you get the benefit on day two, three, and four because it's customized to your needs and you're not dependent on a vendor. But getting started on day one is a very valid point. Because of that, we've recently launched something called Launchpad, which lets you eailylaunch an observability stack, a search application, or any other OpenSearch application, because OpenSearch isn't just observability, there's also search, AI applications, and security monitoring. All this takes a few minutes, and we encourage developers to ask the community if they get lost, even though the documentation is all there. I believe the ease of setting up OpenSearch has been addressed incredibly well and quickly.

On cost, it's a more complicated question. I can tell you OpenSearch is free, but in real life nothing is ever truly free because you still have to run it on infrastructure and manage it.

What OpenSearch does do is make everything cost-effective. Take observability: in the old days, we had to have it because if something in our infrastructure broke, we had to solve it — we couldn't afford downtime — but nobody wanted to pay for it because it was seen as a cost center.

Today the whole language has changed, because OpenSearch gives you a unified view of the context of your data, which is much more cost-effective than doing log analytics, traces, and metrics separately with tools like Grafana and Prometheus, where everyone looked at the data differently and root-cause analysis took five weeks to put the pieces together.

Today it's all in a single pipeline into OpenSearch — you see it all together, through different lenses in the same view, and you can automate resolutions. You can use models and AI to interrogate that data, automate resolutions, and use your observability stack for more than troubleshooting — for company-wide SLOs, understanding acceptable error rates, and understanding cost.

We're in the token economy now, so we can add cost information into traces and logs and understand accurately how much each service is really costing us. Observability isn't just "pay for troubleshooting" anymore — it's become easier to use and a driver of business imperatives.

AI-agent readiness

How AI-agent-ready is OpenSearch, for someone building a project that leans heavily on agentic AI?

Bianca: In the 3.5 release — we've just released 3.7, so we're two minor versions past that — agentic AI became generally available in OpenSearch, and since then it's become a central theme of how people run their search and observability stacks. I think we're ahead of almost any other platform in the world on fully integrated agentic AI.

As you spin up AI agents, OpenSearch is model-agnostic, so you can use any AI model you want. If it's for a search use case, you can monitor those AI agents with the same platform — monitor the trace of the agent, see which services it's calling, what the costs are, and make sure it's doing the right thing. At scale, when you're running 100,000 queries a minute, we can almost let AI monitor AI for security, safety, and compliance.

AI brings scale and the ability to do things quickly. We don't have to work sequentially anymore. But data without context is just data, it's noise. You need a platform that can recall it and spin up AI agents, you need the data underneath it, and you need the agents to talk to each other to perform tasks but without context, all of that is garbage at scale. OpenSearch has built in some features to address this: short-term agentic memory, so an agent remembers the context of what it was asked over the last week or two, and in 3.7, long-term agentic memory as well, which gives us the context we need to take accurate actions on the data. It's already generally available.

AI data layer vs. traditional search

Is OpenSearch now an AI data layer sitting on top of a traditional search stack, or have the two fully merged?

Bianca: I think ultimately OpenSearch will be looked at in a couple of layers. OpenSearch is the application level, and the application level sits on top of an infrastructure that supports the architecture of the application.

What OpenSearch gives you is that it doesn't tie you into any one vendor's choices. You can have that AI infrastructure layer but choose your own infrastructure. You can self-host, or go to one of the hosted services, like our OpenSearch service on NetApp, Oracle, and AWS and choose whatever fits your model. In terms of features and how things run with agentic AI, we don't really say this works better or worse than that. We say everything works and works really well, and with OpenSearch you retain control over how you want to build it, without being tied into any one approach.

On business-source licensing and the Linux Foundation model

This is a bit of an uncomfortable question, more about the Linux Foundation model in general than OpenSearch specifically. MariaDB, Redis, and Elasticsearch all moved from open source to business-source or server-side licenses at some point, largely to protect their business from hyperscalers who weren't contributing enough but were taking their enterprise customers. Then the Linux Foundation and companies like Amazon fork the original project, as happened with Terraform and OpenTofu, and grow it as the "true" open source version while the original gets left behind. Is there an injustice in that, toward the original projects?

Bianca: I think it's a really great question. I don't ever judge a vendor for deciding to close-source or open-source a project. But without intruding into the particulars of how Elastic or AWS felt at the time, which I can't speak to, I can share a personal viewpoint.

If a vendor is the owner of an open source project, to me that open-core label is simply a go-to-market strategy to get users in and then sell services, support, and enterprise capability. It's not what we'd call vendor-neutral. Building a wide community on a vendor-owned open source project is always tricky, and that's why Mongo, Elastic, Redis, and a few others reached a point where the situation became a threat — the go-to-market had been really successful, they'd built a community, but the biggest customers weren't converting.

I find it interesting that Elastic changed back to an open source license after closing it — because they were losing the community, but they'd closed it because they were losing enterprise customers. They were fine with small players using the free product but wanted the big-money customers. The challenge is that often you want your cake and to eat it too. Once you build your brand on community involvement and then tell the community you're closing it, even if you reopen it later, a lot of the community will just say "thanks, but no thanks."

That's the beauty of the Linux Foundation model. It's a nonprofit that nobody owns, and profit isn't the motive. Yes, there will be cases where hyperscalers fork a project. I think it's important to understand that once they fork it and give it to a nonprofit like the Linux Foundation, they give up ownership. They don't own OpenSearch anymore. They could fork it again and keep something in-house, anyone can always do that, but OpenSearch itself can never be closed now, because the Linux Foundation owns it.

OpenSearch itself can never be closed now, because the people that own it is the Linux Foundation.

It also helps to look at where each company actually makes its money. Take Elastic. They make money selling Elasticsearch licenses, whether self-hosted or on the cloud, so it makes sense for them to gate advanced features behind a license, because they have to survive as a business and answer to shareholders.

Hyperscalers like AWS, Microsoft, Google, IBM, and Oracle make their money from selling compute and infrastructure, not directly from the application. Carrying the burden of growing and innovating an application takes away from their core focus of selling infrastructure, so it makes business sense for them to let the community develop the application while they focus on providing a great service to run it, and put their money where they actually make money.

That's the subtle reason hyperscalers are so eager to support Linux Foundation projects. It lets them focus on where they make money, and it guarantees these projects stay open, available, and well-maintained rather than becoming orphaned.

Ultimately it takes time for a project's original founder to say "now we can let the community manage it." What that actually means is that over the years, instead of maintaining the application with a full-time in-house engineering team, the founder becomes one of the companies contributing to a shared engineering effort. You get all the benefit, but the innovation and cost become shared, and the community retains the choices, which is always good for business.

Certifications

Does OpenSearch have plans for a certification track, like Kubernetes has with the CKA?

Bianca: Yes, we've actually recently announced that. The way we're doing it is quite unique and exciting for the open source world. We've already released the first form of learning content, and in a couple of months we're going to release an OpenSearch competency course that carries a badge of competency you can put on LinkedIn.

On top of that, we're going to do the OpenSearch competency certification proper, and based on that certification, we're doing accreditations for different vendors and companies. The follow-up to that is specialist certifications. Since OpenSearch is used across quite a few use cases, we'll have competencies in observability, search, AI applications, and security monitoring. And to renew your certification, instead of retaking the same test every couple of years, as long as you're advancing to more advanced certifications you keep your original qualifications. We want people to grow and advance within OpenSearch.

The biggest misconception about OpenSearch

What's the one thing that most people get wrong about OpenSearch?

Bianca: There are so many things people get wrong about OpenSearch, but I think the biggest one is not recognizing that, as an AI data infrastructure layer, OpenSearch is the only cloud-native, AI-native platform in the world that's truly open source and vendor-neutral. I don't know if people really understand that.

OpenSearch is the only cloud-native, AI-native platform in the world that's truly open source and vendor-neutral.

Maybe if it were named something like "OpenSearch AI" or "OpenAI Search," it would be more recognizable.

Bianca: Yeah because people often equate it to "how does it compare to Elasticsearch?" But conceptually, you can't really compare the two. They'll say "it's like the AWS service," but that's just a vendor who's a member and provides a service on top of it. The platform runs completely independently, within a community that's truly open source. It's not just an AWS project anymore; it's a truly independent, community-owned observability stack.

OpenSearch's 3.7 release, with long-term agentic memory, is already out, and the project's competency certification track is expected to roll out over the coming months. You can find the project's documentation, downloads, and community channels at opensearch.org.

A few weeks back, I invited Brian from the iodé, a de-googled Android project, to have a quick discussion on the project, its achievements and the futuree challenges. I was meant to be in video/audio format but part of discussion suffered from poor audio quality and hence I switch it to nour usual text format.

I hope you enjoy this conversation.

It's FOSS: iodé sits at an interesting crossroads of privacy and sustainability. For those who haven't come across the project before, what is it and what is it trying to accomplish?

Brian: iodé is a project that is interested in making sure that there's a privacy-based Android distribution that is also very easy to use. Very easy for normal users to feel they can use it conveniently.

We also feature a tool which is a tracker blocker, so both your apps and your browser when you're browsing the internet have a sort of firewall that allows you to know exactly which connections your device is making, which connections the apps are making, the browser is making when you're visiting websites, and it prevents ads and trackers from following you around the internet.

That's the main goal and while it's not a Linux device in the classic sense of a Linux mobile device, it's an Android device, it gives you all the usability of an Android device.

It's FOSS: App compatibility is usually the first thing that worries someone considering a de-Googled phone, especially banking apps and anything they'd normally get from the Play Store. Since iodé doesn't ship with Google Play, how do you handle that?

Brian: We have two app stores. We have F-Droid, which is a free software app store that comes by default. And we also have Aurora Store, which is basically a front end for the Google Play Store.

So you can install any app that's on Google Play without Google knowing which apps you're installing it doesn't track you the same way Google Play does, but still gives you all the usability of Google Play.

And the difference is you can also spoof different devices. So if something is not available for your device, you don't have to go to some random APK store and risk downloading something that maybe is a dangerous file. You can just simply change the device settings and spoof another device and download that.

So it gives you all the usability of Google Play, maybe even more so. And like all of our pre-installed apps, you can uninstall any of them and install another app store if you want. You can even install the official Google Play if you want.

It's FOSS: If a non-technical person, someone who just wants their phone to work, switched to iodé tomorrow, what would their day-to-day experience actually look like?

Brian: There may be issues with some banking apps because Google has this integrity API, it's more about monopoly than it is about security.

So there are a few issues users may find with some apps not playing well with Play Integrity API. What we have is called MicroG. It's a Google Play Services emulator, and that usually works for almost any app. All the common apps that you would expect,Instagram, TikTok, all these things, they still work on iodé as you would expect.

So for the average user, unless you have problems with a banking app, and that's not that common, most banking apps continue to work. The only occasional thing I've seen is some apps that are from OEMs, like Samsung Watches, may not work. But in general, most users won't notice a big difference moving over from Android.

The difference you will notice is you don't get a lot of notifications and advertisements and just junk you get in a standard Android distribution, there's an incredible amount of bloatware and ads, especially if you're on something like Xiaomi or OPPO.

It's FOSS: Sustainability is something that sets iodé apart from a lot of other privacy-focused Android projects. You offer refurbished devices alongside new ones. Can you walk us through your thinking on that?

Brian: We're very interested in sustainability and so we encourage people to use refurbished devices when possible. Even some of the Fairphones we offer are refurbished. When you're using a very minimalistic image like iodé, it doesn't have a lot of the bloat and unnecessary software, things that you can't uninstall on a regular stock Android device, which is just running in the background and using up your CPU and using up your RAM.

The system itself is much bigger on stock because of Google Play Services and any other add-ons that OPPO or Xiaomi or any other manufacturer puts in. Because iodé is more minimal, it can run on older hardware, on hardware with lower specifications. So that's why we encourage people to use refurbished devices.

But people are asking, saying, "hey, we want new devices as well." So we have begun to add more new devices to our shop. Initially, we only wanted to work with Shift and Fairphone because they're sort of ethical manufacturers. They look at the entire supply chain, the conflict minerals that are involved in building the phones, and make sure that workers get paid well and that the materials are fairly sourced, and try to make a more sustainable model. Because obviously the best device you can always use is a device that's already been built, in terms of sustainability and ecology. So this is why we focused on refurbished.

It's FOSS: The privacy Android space isn't exactly crowded, but there are notable players like /e/OS, LineageOS, GrapheneOS. Do you see them as part of the same broader community, or more as competitors?

Brian: Honestly, I think anything that's good for any of these projects is going to help the other projects. Of all the Android hardware that's out there, there are very few devices to choose from, probably less than 1% of all Android devices can be de-Googled. There was more interest in custom ROMs back in the day when Android wasn't as useful and when people wanted to customize it. With Play Integrity and the Google Play APIs coming out that made it more difficult to use banking apps and things like that, there was a loss of interest. And also people began to see it as a security problem with unlocked bootloaders.

Now, we try to respect the locked bootloader, which makes us different from other projects like Lineage. Whenever we can relock the bootloader, we do. We have relocked bootloaders on four or five manufacturers. The rest of the manufacturers simply don't allow it. We're trying to work with these other operating systems. We have an agreement through the unified attestation to try to come up with an alternative to Google Play Integrity.

I think there's a big market for these devices. A lot of people just don't know that they can get a device that isn't spying on them, that isn't constantly sending data back to Google or to Apple. And just the fact that these devices exist and work out of the box, many people don't even know or realize this, or they think that it's going to be a huge amount of work to install it. That's why we have a shop, that's why we sell our devices. And if we can help these other projects, I think that's great.

I'd like to see more collaboration, and it would be really good if these groups didn't see each other as competitors. I think the same thing is true of Linux distributions. It would be very absurd for Fedora to be attacking SUSE Linux or Linux Mint. People often distro-hop, and I think the same will be true of privacy-based Android distributions.

It's FOSS: GrapheneOS has at times been quite critical of other projects in this space, including iodé, particularly on security grounds. How do you view that?

Brian: Graphene has been very vocal about saying that we've been attacking them. Actually, I don't think we have. This is probably the first time we'll ever say anything about Graphene. And I think the only thing I will say is that they have a great project, and that it's only available on Pixels. There are some people who want other devices. It is important to have a locked bootloader, but not all hardware manufacturers permit it. While we do lock bootloaders when possible on every system that allows bootloader re-locking, we also want to offer other hardware. And that can lead to security issues on those people's devices.

As for whether we also support end-of-life devices — we do. There's a billion people in the world who are running end-of-life devices, and those devices are vulnerable to attacks that have been found in the code base and aren't getting fixed by manufacturers. We continue to support those devices. I think people should know that if they are worried about security, they shouldn't be running end-of-life devices. But we also don't want people to throw them in the bin. They may have other uses for the device and they may not want that device to be constantly sending data back to Google. So there's a balance here.

There's also the question of the firmware. The firmware is updated by the manufacturer and a lot of those device drivers are actually closed source. We don't have access to be able to change it even if we wanted to. This is kind of one of the problems with the Android ecosystem. It's the same problem that the Linux mobile space is also facing.

We do want to support 60 devices; we don't just want to support Google Pixels. All power to them. I hope that Graphene can also make an agreement with Motorola to allow re-locking bootloaders on their devices. We've already begun to support Motorola devices. We do provide monthly security updates, and we're much more up to date than some of the other custom Android distributions out there. All of these projects are working with very limited resources, and it would be wise if we didn't do any sort of infighting. There's no custom ROM developer that has 30 developers. We're all working with very limited resources.

It's FOSS: Without tracking your users, getting a real picture of adoption must be tricky. What do you actually know about how many people are running iodé?

Brian: We do not really get any information on our user base. We don't keep any information. We just know what happens on the forum. We do know that in the last two years there's been a quarter of a million downloads. There's probably well over 10,000 people running iodé as a daily driver. It's almost doubled in the last year, we think, because there's been a great increase of users, including in the United States. We don't actually sell our devices in the US, so this is a bit of a surprise.

Basically the only thing we can see is the IP of the person downloading the file, and we log this in the sense that we just keep some statistics on which countries are downloading. We have people in the United States, in Germany, and France. And we wipe out these IPs. We just know which country it's coming from.

It's FOSS: To close, if someone is weighing iodé against other privacy-focused Android options, what's your pitch? What makes it worth choosing?

Brian: Aside from monthly security updates and the fact that you can install it on many different devices, we have over 60 devices supported now. I think one of the big things that's really going to interest people, like why to choose iodé over something like Lineage, is that you get an iodé blocker. So you get an integrated tracker blocker, and it's also not going to fill up your VPN slot. On most operating systems, if you install a DNS blocker or an ad blocker, those will usually take up your VPN slot and the VPN slot is also useful for your privacy. So you get kind of the best of both worlds.

One of the things we also focus on is we want there to be a complete suite of apps that's pre-installed, and we want all of those apps to be uninstallable. If you don't like our music player, you just uninstall it. If you don't like the default map app, we use Comaps as a default map app, you can install Google Maps if you want, you can have them both. And you still get all of the privacy advantages of Lineage, because our base is Lineage, with some more improvements. The standard Firefox browser doesn't have any connections back to Google, for instance. But if you wanted to use a different web view, you can also do that.

So you have a lot of choice. But for the average user who doesn't know anything about configuring a device besides "I want to install these four apps," it will still give you much better privacy than a standard stock Android, privacy by default, and the choice to do whatever you want to do with the phone.

I would like to thank Brian for sharing interesting insights about the iodé project. I strongly recommending checking it out, who knows perhaps your next smartphone is powered by iodé.

And if it interests you, you may checkout:

• List of Linux-based smartphons
• Other de-googled Android distros
• and choice of open source smartphone OS