Community Over Code 2026 (ex-ApacheCon) happened from the 11th to the 14th of October in Glasgow (Scotland).
It has been a surprisingly good conference, full of deep technical talks, passion and discussions for the open-source projects we love.
It was so great to find a minimal amount of AI-slop, especially with regard to seeing solutions that don’t just rely on the blind usage of an LLM here and there, but that had technical soundness and depth: I loved it!
It was hugely pleasant and thought-provoking to meet so many fellow Lucene/Solr committers, contributors and practitioners during and after the conference; I think it’s been ages since I’ve met so many in a single place! Didn’t have time to explore the city much, but it was quite easy to meet and continue the discussions after the conference; it was such a great location for many dinners!
The search track during the conference lasted two days, intense and well-rounded. I really appreciate what the committee has done!
There were a lot of interesting talks; our part has been about:
1. Apache Solr 10: What’s Coming up for Vector Search
2. End-to-End Hybrid Search in Apache Solr
On the 12th of October, I and Eric Pugh organised a Lucene/Solr Birds of a Feather (BoF) to collect feedback from the community and assess the status of the projects.
This blog summarises that event. Huge thanks to Andrey Ukhanov, a very active Solr practitioner who took notes during the event. Without his effort, this blog post would not have been possible.
Roughly 10 people participated (with some on and off during the 60-90 minutes of the event), mostly committers and PMC members.
The session started quite informally with a round around the table to gather ideas and topics the community wanted to discuss/get updates on.
Apache Lucene/Solr Case Studies
The first point of discussion was about enriching the Apache Lucene/Solr websites with a section containing current users (companies) to give details on how such organisations use the technologies we love.
There’s clear evidence in the information retrieval community that many people consider Apache Lucene and Apache Solr legacy technologies ‘not used anymore’.
This is far from being the truth; we know it, but we should make this apparent.
Our colleague Lisa, in conjunction with Eric Pugh, is leading the initiative and willing to help formalise this information on the official websites.
So far, we started with the Francelabs Datafari case study (an open-source enterprise search solution built on top of Apache Solr) and the audience at the Birds of a Feather was asked about sharing more.
We didn’t get any formal commitment, but at least there was goodwill from Andrey Ukhanov (Bloomberg) and Anshum Gupta (Apple) to investigate the matter internally.
We know how hard it is for big organisations to approve this sort of publications and internal details, so the effort will be much appreciated, even if it’s just trying, and the Sease team will help interview and curate the related blog post/page.
Wait a minute!
Apache Lucene 10.6, 11 and deprecations
With upcoming Lucene releases, a lot of deprecations are expected to happen (Github-16820): span queries, highlighters, most query parsers (including Complex Phrase Query Parser), and value source.
The general reason behind these deprecations is not driven by performance but rather to reduce the maintenance burden for problematic and potentially superseded features.
This will have impact on Apache Solr that will see a drastic reduction for some of the components available or a move of the same.
It’s not necessarily a bad thing given how many near-identical duplications we have in terms of ways for doing the same thing, but it will definitely require extra care.
New contributors / AI contributors
We noticed a strong influx of new contributors not coming from search-centric companies; this is not necessarily bad but requires extra care as they may have more difficulty recognising what tasks deserve higher priorities, and we may end up flooded with pull requests that are superficial and not aligned with the main project needs.
The advent of AI contributors also created a bottleneck in our pull request review capabilities; all committer involvement is on a volunteer basis, so it’s not easy to scale up our review power.
A possible idea is to ‘gamify’ this and publish a monthly ‘top reviewer’ chart, aiming to build some sort of positive competition.
To reduce the noise, another idea is to limit the number of active pull requests you open unless you are decently active on the dev mailing list (also to reduce the probability of full AI agents with no human supervision).
Finally, reviewers should get more recognition and potentially be automatically added to the changes; this happens already (manually), maybe automating it would be an improvement.
SOME ACTIONS:
- Suggest new contributors to briefly validate their contribution ideas before diving into the code
- Better curate Jira’s priority weight
- Committers to focus on reviewing contributions + also non-committer reviews should happen more frequently – Gamify?
Changes in security
With the help of AI, it’s more frequent to find vulnerabilities (kept private until a release with a fix happens).
Sometimes the huge amount of unfixed vulnerabilities slows down the release cycles, as we tend to fix all the known vulnerabilities and then release.
An option would be to keep the secret list of vulnerabilities and release anyway, including the ones that we are able to fix in a reasonable timeframe. The next release will fix others, from a sort of secret curated backlog.
Evolution of dense vector search
We didn’t manage to talk much about it, but it’s a key topic (partially discussed at our talk).
We are currently mostly following Apache Lucene’s lead and bringing all its features to Solr (sometimes for free, sometimes not).
But what about the future? Do we want to add different engines? (FAISS from Meta, for example)
This topic is up for discussion!
Major version upgrades
We didn’t manage to talk about this as we ran out of time, but it’s a crucial discussion with the different pace we are observing in Apache Lucene and Solr (Apache Lucene to come out before the end of 2026 while we are currently releasing Solr 10.1).
What should happen? Align the release independently of the small number of major releases? Or treat backward compatibility differently in Solr?
Up for discussion!
And that’s the conclusion for the Birds Of A Feather 2026 summary!
What do you think? What are the main pain points of Apache Lucene/Solr in 2026, and what can we do to improve them?
Let us know in the comments!
