Qué es Laravel: lo que esta elección significa para quien encarga un sistema

Lo escrito en la oferta — «PHP 8.4, Laravel 13» — no es un detalle técnico: esas dos líneas deciden cuánto tiempo recibirá el sistema correcciones de seguridad, qué se facturará aparte y cuánto costará entregarlo a otro desarrollador.

La oferta llega un viernes por la tarde y, en su parte técnica, hay dos líneas que en la reunión nadie lee en voz alta: «PHP 8.4» y «Laravel 13». El precio se entiende, el plazo se entiende, y esas dos líneas — qué es Laravel, qué versión de PHP — parecen la cocina interna del proveedor, más o menos tan importantes como con qué taladro se va a perforar el agujero en la pared, así que suelen saltarse como un detalle técnico del que responde otro. La firma, sin embargo, va al pie de todo el documento, y precisamente esas dos líneas deciden cuánto tiempo recibirá el sistema correcciones de seguridad, qué le facturará cada mes además del precio de desarrollo y cuánto costará, dentro de tres años, entregarlo a otro.

Este artículo no va de si PHP es un buen lenguaje y de si Laravel es un buen framework, porque esa pregunta se la contestan los desarrolladores entre ellos y al comprador esa conversación no le sirve de nada práctico. Va de cuatro cosas que el comprador puede comprobar por sí mismo y sin conocimientos técnicos: el calendario de soporte, la licencia, el mercado laboral y las condiciones de entrega. Las cuatro son públicas, tres de ellas son fechas o sumas de dinero, la cuarta es lo que del mercado se puede y no se puede saber, y ninguna depende de lo convincente que esté escrita la oferta — por eso conviene comprobarlas precisamente esa semana en la que todavía se puede hablar del precio.

Qué es Laravel y para qué sirve: el lenguaje y el framework no son una sola elección

PHP es un lenguaje de programación en el que está escrita la parte de servidor del sistema — la que trabaja en el servidor del proveedor o en el suyo y que el usuario nunca ve. Laravel, a su vez, es un framework, es decir, una base de código ya escrita en PHP que resuelve lo que se repite en casi todos los proyectos: el inicio de sesión de los usuarios, las consultas a la base de datos, las colas, el almacenamiento de archivos, el envío de correo. En la oferta aparecen juntos como una sola elección, pero son dos productos distintos, mantenidos por dos equipos distintos con dos calendarios de soporte distintos, y precisamente por eso conviene leerlos por separado.

Hasta qué punto está extendido el lenguaje resulta más difícil de decir de lo que se esperaría. W3Techs, que escanea con regularidad más de veinte millones de sitios web, escribió este agosto que PHP lo usan el 70,2 % de todos los sitios web cuyo lenguaje de programación del lado del servidor esta herramienta conoce. Esa última condición es la que suele desaparecer cuando se copia la cifra en una presentación: no se trata del 70 % de todos los sitios del mundo, sino del 70 % de aquellos que esta herramienta concreta es capaz de reconocer, y además una parte de ese reconocimiento la describe ella misma como inferida de forma indirecta — si la página es WordPress, entonces es PHP.

Al comprador le resulta más útil otra cifra de la misma página. Entre los sitios a los que W3Techs también determina la versión de PHP, el 63,3 % trabaja sobre la octava, el 28,7 % sobre la séptima y el 7,9 % sigue sobre la quinta, aunque la séptima perdió incluso las correcciones de seguridad hace ya cuatro años. Eso significa que aproximadamente un tercio del PHP medible de internet funciona hoy sobre código al que ya nadie hace parches, y no ha ocurrido porque el lenguaje sea malo o porque alguien se equivocara en el desarrollo. Ha ocurrido porque nadie ha encargado ni pagado el cambio de versión, y esta es precisamente la parte del riesgo que el comprador puede tanto ver como gestionar.

El calendario de soporte de PHP es el primer documento que conviene abrir

La regla del grupo de desarrollo de PHP es breve y pública: cada rama de versión recibe soporte completo durante dos años desde la primera versión estable, después dos años más solo de correcciones de seguridad críticas, y al cabo de cuatro años llega el fin de vida y deja de mantenerse por completo. En esa regla hay un detalle que los resúmenes casi siempre recortan: las fechas de fin reales de la tabla se alinean con el último día del año, no con el aniversario de la versión en noviembre, de modo que «dos años desde el lanzamiento» y lo que figura en la tabla de php.net se diferencian en un mes o dos.

En la práctica, eso significa lo siguiente. La versión 8.2 está ahora en la fase de solo correcciones de seguridad, y su soporte termina ya a finales de este año, es decir, dentro de unos cuatro meses. La versión 8.3 perdió el soporte completo a finales del año pasado y recibirá correcciones de seguridad hasta finales de 2027, es decir, unos dieciséis meses más. La versión 8.4 trabajará este año entero en soporte completo y después permanecerá dos años más en solo correcciones de seguridad, mientras que la 8.5 más reciente, que salió en noviembre del año pasado, recibe soporte completo todavía todo el año que viene y correcciones de seguridad hasta finales de 2029.

El soporte de la versión 8.1 terminó el último día del año pasado, y precisamente este caso merece atención si usted ya tiene un sistema, y no una oferta. Si el proveedor lo escribió hace tres años sobre 8.1 y desde entonces nadie ha cambiado nada, hoy trabaja sobre una rama a la que ya no llegan parches de seguridad, y de ello no avisa ni el servidor, ni el navegador, ni el propio sistema. La página se abre exactamente igual que ayer, los clientes no notan nada, y el único sitio donde se puede ver es esta misma tabla pública, que se abre en menos tiempo del que se tarda en leer la portada de la oferta.

El calendario de Laravel es más corto que el de PHP

Laravel formula su política todavía más breve: correcciones de errores dieciocho meses, correcciones de seguridad dos años, y una nueva versión mayor cada año en torno al primer trimestre. Una versión de soporte a largo plazo, que en el sector se llama LTS, hoy ya no existe — en las versiones antiguas sí la había, pero en la tabla de este año esa columna no aparece en absoluto, así que una oferta que escribe «LTS Laravel» describe algo que ahora mismo nadie vende. Es una promesa más corta de la que muchos compradores esperan de un framework sobre el que se construirá el sistema de los próximos cinco años.

En cifras, según la propia documentación de Laravel, el orden es este. Laravel 13 salió en marzo de este año, recibirá correcciones de errores hasta el tercer trimestre del año que viene, y correcciones de seguridad hasta el 17 de marzo de 2028. La ventana de correcciones de errores de Laravel 12 se cerró a mediados de agosto de este año, es decir, diecisiete días antes de escribir estas líneas, y sus correcciones de seguridad terminarán en febrero del año que viene. El soporte de seguridad de Laravel 11 terminó en la primavera de este año, de modo que un sistema que hoy trabaja sobre la undécima versión ya trabaja sin parches, por muy bien que se vea desde fuera.

Fíjese en que el fin de las correcciones de errores de Laravel 13 se indica como un trimestre, no como una fecha concreta. Es una imprecisión de la propia formulación de Laravel, y no es un problema mientras se copie exactamente como está; el problema empieza en el momento en que el proveedor o el comprador lo redondean a un día concreto y después planifican el presupuesto sobre un número que no está en la fuente. Otro límite que hay que conocer antes de elegir la versión: Laravel 13 exige como mínimo PHP 8.3, así que un sistema sobre la decimotercera versión no se puede dejar en 8.2 ni siquiera si la propia 8.2 todavía recibiera correcciones de seguridad durante un tiempo.

Qué significan los dos calendarios juntos para el sistema que encarga hoy

Si el sistema se entrega sobre Laravel 13 junto con PHP 8.4 u 8.5, la primera fecha en la que algo tiene que moverse obligatoriamente es marzo de 2028, cuando terminan las correcciones de seguridad de Laravel, y eso es aproximadamente dieciocho meses y medio desde hoy. PHP no es el límite en esta combinación, porque ambas ramas reciben correcciones de seguridad más tiempo que el framework, así que lo primero que envejece es Laravel, no el lenguaje. Esa es también la única forma honesta de responder a la pregunta «cuánto tiempo aguantará este sistema sin una inversión adicional»: no con una sensación, sino con la más temprana de las dos fechas públicas.

Si el mismo sistema se entrega sobre Laravel 13 pero PHP 8.3, el orden se invierte y el primer plazo llega en unos dieciséis meses, cuando terminan las correcciones de seguridad de esta rama de PHP. Si el proveedor escribe sobre Laravel 12, que para un proyecto existente sigue siendo una elección perfectamente normal, las correcciones de seguridad terminan en febrero del año que viene, y la vida del sistema nuevo empieza con seis meses hasta el primer cambio de versión obligatorio. La diferencia entre la primera y la tercera variante es un año que se puede ganar en una sola conversación antes del contrato, y que después de la firma ya no se puede comprar.

Hay dos errores en esta cuenta tan extendidos que conviene nombrarlos por separado. El primero es confundir el soporte completo con el de seguridad, así que al oír que «el soporte de PHP 8.4 termina a finales de año» conviene preguntar cuál de las dos ventanas se quiere decir: termina la corrección de errores ordinarios, pero las correcciones de seguridad llegan dos años más. El segundo es creer la frase del propio Laravel de que el paso a una nueva versión mayor suele llevar un día o menos; es un objetivo formulado por los desarrolladores, no un promedio medido, y en un contrato no se puede escribir como plazo.

La licencia cuesta cero, y eso es verdad solo del lenguaje y del framework

El framework Laravel se distribuye con licencia MIT, una de las licencias de código abierto más simples, que permite usar, modificar y revender el código con el único requisito de conservar el aviso de derechos de autor. Con PHP es un poco más complejo, y esa complejidad es actual precisamente ahora, porque la licencia cambia: las versiones hasta la 8.5 inclusive salen con la revisión 3.01 de la licencia PHP, y a partir de la 8.6 pasan a la cuarta revisión, que el propio php.net describe como licencia «Modified BSD» y que en la práctica coincide con BSD-3-Clause. En ninguna de estas variantes está prevista una cuota.

Eso significa que por el propio lenguaje y el propio framework la empresa no paga ni por usuario, ni por núcleo de procesador, ni por año, y ese cero no es una promoción que vaya a caducar. Como comparación vale el modelo que usa Microsoft SQL Server: allí se licencia o por núcleos, o por servidor junto con licencias de acceso de cliente; la edición Standard está limitada a lo menor entre cuatro zócalos de procesador o veinticuatro núcleos, y la edición Express gratuita, a un zócalo o cuatro núcleos. Aquí no escribimos importes exactos, porque el tarifario cambia y hay que leerlo en Microsoft; al comprador lo comparable es el modelo, no la cifra — un producto factura según el volumen de hardware, el otro no factura en absoluto.

En una contratación eso tiene dos consecuencias que conviene anotar de inmediato. La primera es agradable: no hay auditoría de licencias, no hay recálculo anual por usuarios que han crecido a lo largo del año, y no hay la situación en la que el proveedor de software aparece a los tres años con una factura por un límite superado. La segunda es la que suele olvidarse: el código abierto quita la dependencia del dueño del framework, pero no quita la dependencia en general. La dependencia se desplaza a otros sitios — a la agencia, que es la única que sabe cómo está montado el proyecto, a los productos de pago que están junto al código, a un abandoned package que ya nadie mantiene, y a una versión mayor cuyo soporte ha terminado. Esos cuatro sitios son los que el comprador tiene que comprobar, porque la línea de la licencia no dice nada de ellos.

Dónde Laravel empieza a cobrar de todos modos: productos que no son el framework

El mismo equipo que mantiene Laravel vende también varios productos, y en la oferta suelen aparecer en la misma línea que el framework, como si fueran parte de él. Laravel, en su propio sitio web, separa las dos cosas: los paquetes — Horizon, Telescope, Pulse, Scout, Sanctum, Octane y otros — tienen licencia MIT y son gratuitos, mientras que los productos son Cloud, Forge, Nightwatch, Vapor y Nova, y se pagan cada mes o cada año. Envoyer se sigue vendiendo por separado. Ninguno de estos productos es necesario para que un sistema Laravel funcione, y precisamente por eso su presencia en la oferta es una elección, no una necesidad.

Los precios, este agosto, eran estos. Forge, con el que se administran servidores, cuesta 12, 19 o 39 dólares estadounidenses al mes según el plan. Nova, que es un panel de administración, cuesta 99 dólares una vez por un proyecto junto con actualizaciones de un año y 79 dólares al año por continuar las actualizaciones; la licencia ilimitada cuesta 299 y 249 dólares respectivamente, y además cubre sus propios proyectos, no los de sus clientes. Nightwatch, que recoge los eventos del sistema, empieza con un plan gratuito y sube a 20, 60 y 300 dólares al mes, más un recargo por eventos por encima del límite incluido. Laravel Cloud empieza en 5 dólares al mes más consumo, y Envoyer cuesta de 10 a 50 dólares al mes.

La pregunta para el comprador no es si estos productos son buenos, porque por lo general lo son y ahorran al desarrollador varios días al mes. La pregunta es cuáles de ellos están incluidos en el precio nombrado, en qué cuenta están registrados y qué ocurre con ellos si usted cambia de proveedor dentro de dos años. Una suscripción que está en la cuenta de la agencia y no se menciona en el contrato es precisamente la dependencia que la licencia MIT no quita, porque MIT habla del código, no de la cuenta en la que se despliega y se vigila.

Qué ocurre si el desarrollador desaparece

«El código lo puede retomar cualquier desarrollador de Laravel» es una frase jurídicamente cierta y prácticamente incompleta, y la hemos escrito también nosotros. La licencia MIT sí permite a otra empresa trabajar con ese código, sin pedir permiso ni a nosotros ni al equipo de Laravel. Si el nuevo desarrollador será útil ya la primera semana, lo deciden otras cuatro cosas, y las cuatro se pueden comprobar antes de que el contrato esté firmado.

La primera es la versión mayor. Entregar un Laravel 11 a un equipo nuevo no es una entrega, sino un proyecto de cambio de versión, porque el soporte de seguridad ya ha terminado y el primer trabajo no será funcionalidad nueva, sino el salto de versión atrasado hasta un lanzamiento con soporte. La segunda es la distancia respecto a la convención del framework: la documentación de Laravel asume una disposición determinada de carpetas y clases, y cuanto más se ha alejado el proyecto de ella, más cara es la toma de contacto. Aquí no hay cifra y no la hay en ninguna fuente, solo hay una tendencia; en cambio el comprador puede preguntar de forma muy concreta qué se ha escrito en el proyecto en contra del valor por defecto y qué necesidad lo exigía.

La tercera son las dependencias, es decir, los paquetes ajenos en los que se apoya el sistema. Composer, que en el mundo Laravel las gestiona, guarda un archivo con las versiones exactas, y es valioso precisamente porque un desarrollador nuevo puede instalar exactamente lo mismo que veía el anterior, no lo que hoy es lo más reciente. Lo que este archivo no garantiza son dos cosas: que el paquete siga disponible para descarga, y que desde entonces no se haya encontrado una vulnerabilidad. El comando composer audit muestra ambas en una sola llamada, y es la forma más corta de pregunta que se puede hacer sobre una base de código ajena.

La cuarta es un abandoned package, y aquí las palabras engañan. Packagist, el catálogo público de Composer, marca que los mantenedores se han detenido, pero eso no significa que el paquete desaparezca o deje de funcionar: swiftmailer se sigue sirviendo, tiene 449 millones de instalaciones registradas, el último lanzamiento es de 2021 y, al mismo tiempo, tiene tres vulnerabilidades conocidas. En la propia base de código de este sitio, que es Laravel 13 junto con el panel de administración Filament, hay 109 paquetes de producción y ningún abandoned package — es nuestra cifra sobre nuestro proyecto, no una media del sector, porque una media publicada del sector no existe en ningún sitio.

Qué tamaño tiene el mercado laboral, y por qué nadie dará una cifra exacta

A la pregunta de si en Letonia es fácil encontrar a alguien que retome el sistema, la respuesta honesta es que no existe estadística pública sobre desarrolladores de PHP o de Laravel en Letonia. Hay datos indirectos, y valen exactamente tanto como la precisión con la que se describen. En la encuesta PHP de JetBrains del año pasado, entre 1.720 personas para las que PHP es el lenguaje principal, el 64 % trabaja con Laravel, el 25 % con WordPress y el 23 % con Symfony; el trabajo de campo fue en primavera, la encuesta está sesgada a favor de los usuarios de las herramientas de JetBrains, lo que la propia empresa reconoce, y los grupos de encuestados más grandes vienen de Japón, Estados Unidos, Rusia, China y Francia, no del Báltico.

A escala europea, Eurostat informó en mayo de este año de que el año pasado trabajaban en la Unión Europea 10,45 millones de especialistas en tecnologías de la información y la comunicación, el 5,0 % de todos los ocupados y un 2,6 % más que el año anterior. Sobre Letonia, en una recopilación anterior de la misma fuente hay otra cifra, más útil para el comprador que el crecimiento conjunto: en 2023 solo el 4,48 % de las empresas letonas buscaba o intentaba contratar a estos especialistas, el indicador más bajo de toda la Unión, y entre las empresas europeas que buscaban, el 57,5 % no consiguió cubrir la vacante.

Estas cifras son sobre especialistas del sector en conjunto, no sobre PHP, y no deben reescribirse como una afirmación sobre el mercado laboral de Laravel en Letonia — ni por nosotros, ni por el proveedor que las cite en su oferta. Nosotros mismos hemos escrito en nuestra página de servicio que es fácil encontrar desarrolladores que retomen el trabajo; al preparar este artículo no encontramos fuente para esa afirmación, así que aquí no la repetimos. La secuencia práctica para el comprador es, de todos modos, otra: no creer en el tamaño del mercado, sino conseguir que la base de código sea de aquellas en las que un recién llegado entra a bajo coste, independientemente de cuántas de esas personas haya.

Dónde trazamos nosotros mismos el límite en la oferta

Escribimos Laravel desde 2013, cuando salió su cuarta versión, y eso significa en la práctica que hemos pasado varias veces exactamente por aquello de lo que este artículo avisa: un cambio de versión mayor que no es trabajo de un día y que no se puede hacer entre otras tareas. En nuestra página de desarrollo de sistemas con Laravel hay precio y plazos, y esa es otra conversación; en este artículo está solo lo que en una oferta se puede comprobar con independencia de quién la haya escrito y de lo bien que esté escrita.

Lo que no afirmamos es que cualquier desarrollador retome cualquier base de código con la misma facilidad, porque la sección anterior dice lo contrario. Lo que afirmamos es más concreto y más comprobable: el repositorio es del cliente desde el primer día, en él están el archivo de dependencias, la documentación y la configuración de despliegue, y en el momento de la entrega la versión es la que en ese momento todavía recibe correcciones de seguridad. Si le parece que la elección es en realidad entre un producto ya hecho y un sistema a medida, entonces es otra conversación, que hemos escrito por separado, y si la pregunta es precisamente una tienda online, entonces la comparación entre WooCommerce y Laravel responde con más precisión que este artículo.

En la práctica, el paquete de entrega incluye el repositorio con todo el historial, el archivo de dependencias con las versiones exactas, un README con los pasos de arranque, la configuración de despliegue y el acceso a todas las cuentas en las que funciona el sistema. Eso es lo que se puede prometer y comprobar. Lo que no se puede prometer es el mercado: cuántas personas en Letonia tomarán este trabajo y a qué precio no está en nuestras manos ni en ninguna estadística pública, así que esta pregunta no la respondemos con una cifra convincente. Lo único que aquí trabaja de verdad a favor del comprador es que la base de código es ordinaria, la versión tiene soporte y la documentación está escrita en ese momento, no aplazada a la semana de la entrega.

Qué preguntar antes de firmar

La primera pregunta es sobre las fechas: qué versión mayor de Laravel y qué rama de PHP estarán en el sistema el día mismo de la entrega, y cuándo terminan sus correcciones de seguridad. La respuesta son dos fechas, las dos se pueden comprobar en dos páginas públicas en cinco minutos, y hay que escribirlas o en el contrato o al menos en la correspondencia. Si el proveedor nombra una versión cuyo soporte termina antes que el plazo de garantía, eso no está prohibido y a veces está incluso justificado, pero entonces las dos partes tienen que saberlo, y en el precio tiene que quedar claro quién pagará el paso.

La segunda pregunta es sobre las suscripciones: qué productos de pago — Forge, Cloud, Nova, Nightwatch, Vapor o Envoyer — hacen falta para el funcionamiento del sistema, cuánto cuestan al mes en conjunto y en qué cuenta están. La tercera es sobre el repositorio: desde qué día es suyo, si contiene el archivo de dependencias y si en la comprobación automática está incluido el comando composer audit. La cuarta es la pregunta de dinero que suele aplazarse y que después aparece por sorpresa en el presupuesto: quién pagará el cambio de versión mayor dentro de año y medio y si entra en el contrato de mantenimiento o será un encargo nuevo.

Ninguna de estas cuatro preguntas exige que usted entienda el código, y ninguna debe tomarse como desconfianza hacia el proveedor. Todas van de lo que ocurrirá después de que el proyecto esté terminado y la factura pagada, y un buen proveedor las responde de inmediato, porque esas fechas las sabe de memoria. Si la respuesta a alguna de ellas lleva una semana o se convierte en una explicación de por qué la pregunta no importa, esa ya es una respuesta.

Estas cuatro preguntas no sustituyen una evaluación técnica y no responden a si la arquitectura propuesta es buena, pero eliminan la mayor parte de las sorpresas desagradables que suelen llegar el segundo o el tercer año, cuando el entusiasmo inicial se ha acabado y el sistema simplemente funciona. Si tiene una oferta en la mano y no está seguro de lo que las versiones escritas en ella significan para sus plazos y su presupuesto, escríbanos — la respuesta a estas cuatro preguntas se puede preparar sin abrir el código.