OpenEvolve is increasingly being used as a baseline for research on self-evolving LLM agents and MAP-Elites-style evolutionary systems.
A common research direction is studying evolutionary dynamics, such as:
- island selection policies
- adaptive migration strategies
- exploration vs. exploitation trade-offs
- diversity-aware population management
At the moment, these mechanisms appear to be implemented inside the core evolution loop. As a result, researchers often need to fork and modify internal OpenEvolve code in order to evaluate alternative strategies.
This creates several issues:
- Different papers end up using incompatible forks of OpenEvolve.
- Reproducing results becomes more difficult.
- Small algorithmic changes require maintaining large code patches.
Would it make sense to expose island selection (or more generally population-management decisions) through a pluggable strategy interface?
For example:
run_evolution(
...,
island_selector=my_selector,
)or
run_evolution(
...,
strategy=CustomIslandStrategy(),
)This would allow experimentation with alternative evolutionary policies while keeping the rest of the OpenEvolve implementation unchanged, improving comparability and reproducibility across research projects.
Curious whether this aligns with the project's roadmap.
Additional Motivation
As a concrete example, I am currently developing an evolutionary deep learning verification framework that uses evolutionary search to explore and validate model behaviors.
One of the goals is to reuse OpenEvolve as a foundational evolutionary component, in a similar spirit to how researchers build on DEAP rather than modifying its internals for every experiment.
During integration, I found that experimenting with alternative island-selection and population-management policies currently requires modifying OpenEvolve's internal evolution loop. This makes it difficult to compare strategies while keeping the rest of the system unchanged.
A pluggable strategy interface would not only benefit my use case. Still, it could also make OpenEvolve easier to adopt as a reusable research platform for studying evolutionary dynamics, adaptive search policies, and future MAP-Elites variants.
OpenEvolve is increasingly being used as a baseline for research on self-evolving LLM agents and MAP-Elites-style evolutionary systems.
A common research direction is studying evolutionary dynamics, such as:
At the moment, these mechanisms appear to be implemented inside the core evolution loop. As a result, researchers often need to fork and modify internal OpenEvolve code in order to evaluate alternative strategies.
This creates several issues:
Would it make sense to expose island selection (or more generally population-management decisions) through a pluggable strategy interface?
For example:
or
This would allow experimentation with alternative evolutionary policies while keeping the rest of the OpenEvolve implementation unchanged, improving comparability and reproducibility across research projects.
Curious whether this aligns with the project's roadmap.
Additional Motivation
As a concrete example, I am currently developing an evolutionary deep learning verification framework that uses evolutionary search to explore and validate model behaviors.
One of the goals is to reuse OpenEvolve as a foundational evolutionary component, in a similar spirit to how researchers build on DEAP rather than modifying its internals for every experiment.
During integration, I found that experimenting with alternative island-selection and population-management policies currently requires modifying OpenEvolve's internal evolution loop. This makes it difficult to compare strategies while keeping the rest of the system unchanged.
A pluggable strategy interface would not only benefit my use case. Still, it could also make OpenEvolve easier to adopt as a reusable research platform for studying evolutionary dynamics, adaptive search policies, and future MAP-Elites variants.