Europe Alternatives

Criterios de inclusion

Europe Alternatives lista tanto empresas europeas comerciales como proyectos open-source. Cada tipo tiene sus propios criterios de inclusion descritos a continuacion.

Empresas comerciales

1. Sede europea

La empresa debe tener su sede en un pais europeo. No se limita a los estados miembros de la UE: las empresas de cualquier pais europeo califican, incluyendo los del EEE, AELC y otras naciones europeas.

2. Propiedad mayoritariamente europea

La mayoria de los accionistas de la empresa deben ser europeos. Si una empresa europea tiene una empresa matriz o un accionista mayoritario que no es europeo, no califica para ser listada. Esto asegura que las empresas listadas esten genuinamente controladas por europeos.

3. Servicio SaaS o en la nube

La empresa debe ofrecer un producto o servicio de software como servicio (SaaS) o basado en la nube. Esto incluye software alojado, infraestructura en la nube, servicios de plataforma y otras soluciones entregadas por web.

Paises europeos y acuerdos comerciales

Como referencia, los siguientes son los principales bloques economicos y acuerdos europeos. Las empresas con sede en cualquiera de estos paises son elegibles.

Union Europea (UE) — 27 estados miembros

Alemania, Austria, Belgica, Bulgaria, Chipre, Croacia, Dinamarca, Eslovaquia, Eslovenia, Espana, Estonia, Finlandia, Francia, Grecia, Hungria, Irlanda, Italia, Letonia, Lituania, Luxemburgo, Malta, Paises Bajos, Polonia, Portugal, Republica Checa, Rumania, Suecia

Espacio Economico Europeo (EEE) — 30 paises

Los 27 estados miembros de la UE mas Islandia, Liechtenstein y Noruega. El EEE extiende el mercado interior de la UE a estos tres paises de la AELC, proporcionando libre circulacion de bienes, servicios, capital y personas.

Asociacion Europea de Libre Comercio (AELC) — 4 paises

Islandia, Liechtenstein, Noruega y Suiza. Mientras que Islandia, Liechtenstein y Noruega participan en el EEE, Suiza mantiene su relacion con la UE a traves de acuerdos bilaterales.

Otros paises europeos

Reino Unido, Ucrania, Moldavia, Albania, Serbia, Montenegro, Macedonia del Norte, Bosnia y Herzegovina, Kosovo, Georgia, Armenia, Turquia (parte europea), Monaco, Andorra, San Marino y Ciudad del Vaticano. Las empresas de estos paises tambien son elegibles para ser listadas.

Proyectos Open-Source

Los proyectos open-source se listan en una tabla separada. A diferencia de las empresas comerciales, no requieren sede ni propiedad europea. Para ser listado, un proyecto debe cumplir los siguientes criterios.

1. Licencia open-source reconocida

El proyecto debe publicarse bajo una licencia open-source reconocida por la OSI (por ejemplo, MIT, Apache 2.0, GPL-3.0, AGPL-3.0, MPL-2.0). Los proyectos que usan licencias “source available”, “no comercial”, “Commons Clause” o similares no califican.

2. Auto-alojable con documentacion oficial

El proyecto debe ser realista de auto-alojar, con documentacion oficial de instalacion y al menos una ruta de despliegue estandar, como:

  • Docker y Docker Compose
  • Charts de Helm o manifiestos de Kubernetes
  • Paquetes de sistema operativo (deb, rpm, etc.)

“Solo compilar desde el codigo fuente” sin una guia clara de despliegue no es suficiente.

3. Mantenido activamente

El proyecto debe mostrar mantenimiento continuo: un lanzamiento o actividad significativa de commits en los ultimos 12 meses. Se puede hacer una excepcion para proyectos explicitamente en “modo de mantenimiento” si su documentacion de operaciones y seguridad es solida.

4. Operacionalmente utilizable (Day-2 Readiness)

La documentacion debe cubrir al menos las siguientes areas para asegurar que el proyecto sea viable para uso en produccion mas alla de la instalacion inicial:

  • Actualizaciones y migraciones — como actualizar de forma segura entre versiones
  • Respaldo y restauracion o exportacion/importacion — como proteger y mover datos

5. Contacto de seguridad / ruta de divulgacion

El proyecto debe proporcionar una forma clara de reportar vulnerabilidades de seguridad de manera responsable. Los metodos aceptables incluyen:

  • Un archivo SECURITY.md en el repositorio
  • Una direccion de correo electronico dedicada a seguridad
  • Un proceso documentado de divulgacion o programa de recompensas por errores

6. Sin “trampa SaaS”

La version auto-alojada debe ser significativamente utilizable sin requerir un backend propietario en la nube del proveedor para la funcionalidad principal. Las caracteristicas pueden diferir entre ofertas auto-alojadas y alojadas por el proveedor, pero el producto principal debe funcionar de manera independiente.