Introducción
Cinco años después del fork original que separó OpenSearch de Elasticsearch, la narrativa ya no es sobre licencias o disputas legales entre Elastic y Amazon. La conversación técnica actual gira en torno a una pregunta más pragmática: ¿es OpenSearch una plataforma independiente lo suficientemente sólida para reemplazar a las suites comerciales atadas por contratos multianuales? Los datos recientes publicados por la Linux Foundation y el propio proyecto indican que la dependencia absoluta de AWS se está diluyendo, pero no ha desaparecido. Para los equipos de infraestructura y DevOps, entender esta transición es crítico al evaluar si migrar desde Elasticsearch o servicios gestionados propietarios representa una reducción real del riesgo tecnológico o simplemente un cambio de proveedor con nuevos vectores de bloqueo (vendor lock-in).
El reciente informe «Open Data Infrastructure Report 2026» deja ver cifras que contradicen la idea de que OpenSearch es solo una herramienta de AWS envuelta en código abierto. Sin embargo, la brecha entre la realidad técnica del proyecto y la percepción del mercado sigue siendo amplia. Los administradores de sistemas enfrentan el desafío de distinguir entre el ruido mediático sobre la neutralidad del vendor y los hechos operativos: quién mantiene el código hoy, qué porcentaje de contribuciones externas existen y cómo impacta esto en la evolución de características críticas para cargas de trabajo modernas como RAG (Retrieval-Augmented Generation).
Qué ocurrió
La transferencia de OpenSearch a la Linux Foundation en septiembre de 2024 fue, según palabras textuales de Bianca Lewis, directora ejecutiva de la Fundación, un «momento decisivo». Este movimiento no fue meramente simbólico; alteró la estructura de gobernanza y eliminó la capacidad de AWS para cerrar el proyecto o modificar unilateralmente su licencia. Antes de esta transición, OpenSearch existía bajo la sombra directa de una corporación con objetivos comerciales alineados a la venta de cómputo, no necesariamente al desarrollo a largo plazo de la capa de aplicación de búsqueda.
Los datos de contribución reflejan este cambio estructural. En el primer año tras el fork (2021-2022), AWS generaba el 91% de todas las actividades de contribución en los repositorios del proyecto. Hacia 2025-2026, esa cifra descendió al 72%. Paralelamente, la composición de los mantenedores principales (maintainers) del repositorio core experimentó una diversificación similar: si bien en abril de 2022 los ingenieros afiliados a Amazon representaban el 95% de quienes tenían derechos de merge final, hoy esa proporción se sitúa en el 71%. Aunque sigue siendo una mayoría abrumadora, la tendencia indica una apertura gradual hacia contribuciones externas que están ganando tracción.
Este cambio también se manifiesta en las estrategias de despliegue corporativo. El informe señala que las implementaciones autogestionadas (self-managed) en la nube crecieron más rápido que el servicio gestionado de Amazon (Amazon OpenSearch Service). En 2024, solo el 37% de los usuarios ejecutaban instancias autogestionadas; ahora esa cifra llegó al 60%. Por otro lado, el uso del servicio gestionado de AWS subió modestamente del 44% al 48%. Este dato es revelador: las organizaciones están optando por operar OpenSearch bajo su propia gestión técnica para evitar ataduras contractuales con un único cloud provider, aunque mantengan la infraestructura de cómputo en AWS.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para los equipos de SRE y seguridad, la independencia percibida afecta directamente la gestión del riesgo de cadena de suministro de software (SBOM). Si una organización depende críticamente de OpenSearch para funciones de observabilidad o búsqueda semántica, necesita garantizar que las actualizaciones de seguridad y las nuevas características no estén sujetas a los ciclos de lanzamiento internos de un único proveedor corporativo. La reducción en el porcentaje de contribuciones de AWS mitiga parcialmente este riesgo, pero la presencia continua de ingenieros de Amazon en roles clave de gobernanza técnica mantiene una influencia significativa.
Desde la perspectiva de Cloud FinOps, el cambio hacia despliegues autogestionados permite a las empresas optimizar costes mediante el uso de instancias spot o reservadas específicas para los nodos de datos, separando el costo de cómputo del costo de la licencia o servicio gestionado. No obstante, esta autonomía conlleva una carga operativa mayor: equipos de DevOps deben asumir la responsabilidad completa del parcheo, escalado y recuperación ante desastres que antes delegaban al servicio gestionado de AWS.
Además, la percepción de neutralidad influye en la adopción por parte de empresas que compiten directamente con AWS o que buscan evitar conflictos de interés estratégicos. Según el informe, casi un cuarto (24%) de los usuarios que aún no adoptaron OpenSearch citan preocupaciones sobre la vecindad con AWS como razón principal para quedarse fuera. Esto sugiere que, a pesar de los cambios técnicos y legales, el «brand awareness» negativo o la desconfianza histórica siguen siendo barreras comerciales reales que impactan en la velocidad de adopción empresarial.
Detalles técnicos
La arquitectura técnica de OpenSearch ha divergido significativamente del código base original de Elasticsearch 7.x. Bianca Lewis reconoce que las primeras versiones eran, esencialmente, «Elasticsearch con otro nombre», incluyendo documentación y plugins idénticos. Sin embargo, la versión actual (OpenSearch 3.9, lanzada en septiembre) incorpora mejoras sustanciales orientadas a cargas de trabajo de Inteligencia Artificial, específicamente para escenarios de búsqueda vectorial e híbrida necesarias en RAG.
Un aspecto crítico es la gobernanza técnica. Aunque AWS posee solo cuatro de los quince asientos con derecho a voto en el Comité Directivo Técnico (TSC), un empleado de AWS (Andrew Ross) fue reelegido presidente del comité en octubre. Esta concentración de liderazgo técnico explica por qué, a pesar de la diversificación en contribuciones casuales, la dirección estratégica del proyecto sigue alineada ampliamente con las necesidades de la infraestructura cloud masiva que Amazon opera.
Otro dato relevante para los equipos de plataforma es el estado de madurez de las implementaciones. El informe indica que una proporción sustancial de los despliegues actuales son experimentales o están en fase de evaluación. Muchas organizaciones mantienen contratos vigentes con Elastic (licencias de 5 años) o Splunk (contratos de 3 años), lo que les impide realizar cambios inmediatos. Por tanto, OpenSearch se está posicionando como la opción «por defecto» para infraestructura AI abierta, pero su consolidación como reemplazo total de plataformas comerciales depende de la expiración de estos ciclos de licenciamiento tradicionales.
Qué deberían hacer los administradores y equipos técnicos
- Auditar la dependencia operativa: Si actualmente usan Amazon OpenSearch Service, evalúen el coste operativo de migrar a una implementación autogestionada en Kubernetes o EC2. Utilicen herramientas como Terraform para definir la infraestructura como código, permitiendo la portabilidad entre proveedores cloud si fuera necesario:
terraform init && terraform plan -var="opensearch_version=3.9"- Monitorear la gobernanza: Inscríbanse en las listas de correo de la OpenSearch Software Foundation para seguir el debate del TSC. La neutralidad no es estática; requiere observación continua de quién propone y aprueba cambios en APIs críticas.
- Evaluar casos de uso AI/RAG antes que legacy search: Si bien OpenSearch puede reemplazar búsquedas textuales simples, su mayor valor diferencial hoy reside en capacidades vectoriales. Realicen pruebas de carga específicas para hybrid search (BM25 + KNN) antes de considerar una migración completa desde Elasticsearch:
# Ejemplo de configuración de índice para búsqueda híbrida
settings:
index.knn: true
mappings:
properties:
embedding_vector:
type: knn_vector- Planificar la salida: Si están atados a contratos con Elastic o Splunk, comenzarán pruebas piloto de OpenSearch ahora para reducir el riesgo técnico cuando finalicen los ciclos de licenciamiento. La curva de aprendizaje en operadores y herramientas de monitoreo (como OpenSearch Dashboards vs. Kibana) debe calcularse en la hoja de ruta de 2027.
Conclusión
OpenSearch ha logrado un hito crucial al reducir la dependencia exclusiva de AWS, pasando del 91% al 72% en contribuciones y diversificando su base de mantenedores. La transferencia a la Linux Foundation garantizó la supervivencia jurídica y licenciosa del proyecto, asegurando que no pueda ser cerrado o relicenciado unilateralmente por una sola corporación. Sin embargo, la realidad técnica muestra que AWS sigue siendo el actor dominante en la dirección estratégica del código.
Para los equipos de infraestructura, OpenSearch representa hoy una opción viable y potente, especialmente para cargas de trabajo de IA y búsqueda vectorial, pero no es una solución «plug-and-play» libre de riesgos de gestión. La decisión de adoptarlo debe basarse no solo en el ahorro potencial de licencias, sino en la capacidad del equipo interno para gestionar la complejidad operativa adicional que conlleva abandonar los servicios totalmente gestionados. La neutralidad es un proceso, no un estado final; OpenSearch está caminando hacia ella, pero aún respira bajo la sombra técnica de su creador original.
Fuentes
https://thenewstack.io/opensearch-foundation-aws-elasticsearch/