La semana en la que dos fallos graves de PHP obligaron a medio internet a parchear de urgencia, la fundación que sostiene el lenguaje explicaba cómo funciona por dentro. Elizabeth Barron, su directora ejecutiva, lo resumió en una frase: hay una persona a tiempo completo, que es ella, y catorce colaboradores en su mayoría a tiempo parcial. El consejo no cobra y el dinero llega de donaciones y subvenciones.
PHP puede estar detrás de hasta el 70% de los sitios del mundo, según las estimaciones que se manejan en el sector. Esa cifra convive con una estructura que cabe en una sala pequeña, y el contraste no es una anécdota: es la descripción del modelo sobre el que se ha construido buena parte de la web.
La comparación con el incidente de esta semana es inevitable. Los parches que se publicaron el miércoles salieron de un equipo que trabaja con investigadores externos y con empresas como OpenAI, Wiz y Calif, y que coordina la respuesta desde una organización sin ánimo de lucro. Lo contamos al analizar el fallo de php2shell y su impacto en la cadena de desarrollo: el problema técnico era grave, y la pregunta que queda es quién paga el siguiente.
Una plantilla «inaceptable»
Con una persona a tiempo completo y catorce parciales, la fundación no puede permitirse el lujo de revisar todo lo que llega. Su papel es coordinar, financiar a quienes investigan y mantener la infraestructura del proyecto, mientras el código lo escriben voluntarios que trabajan en otras empresas.
Ese modelo funciona cuando hay pocas propuestas y se rompe cuando el volumen crece. Barron ha explicado que el proyecto recibe casi el doble de cambios de código propuestos que hace un año, y que el número de colaboradores no se ha duplicado. Revisar esas contribuciones exige tiempo de personas con experiencia, que es el recurso más escaso.
La segunda consecuencia es la dependencia de terceros. Cuando aparece un fallo crítico, la fundación trabaja con investigadores y compañías que aportan análisis y capacidad de prueba. Es una red útil y también un recordatorio de que la seguridad del lenguaje depende de que esas empresas sigan teniendo interés en colaborar.
El doble filo de la inteligencia artificial
El episodio de esta semana deja un dato interesante sobre el papel de la IA en el software libre. Los dos fallos llevaban una década en el código y se encontraron con ayuda de herramientas automáticas, que permiten revisar volúmenes de código que antes eran inabarcables.
Ese mismo avance genera trabajo. Si cualquier persona puede generar un parche con un modelo, el número de propuestas sube, y cada una necesita revisión humana para no introducir un problema mayor. La fundación lo ha descrito sin adornos: más cambios, mismos revisores.
Es un patrón que se repite en otros proyectos. Lo vimos en el análisis del 25% de propuestas generadas por IA en el software libre, donde la conclusión era que el cuello de botella se ha movido de escribir código a revisarlo. La IA abarata la primera parte y no toca la segunda.
| Recurso |
Situación descrita |
| Personal a tiempo completo |
1 persona (la directora ejecutiva) |
| Colaboradores |
14, en su mayoría a tiempo parcial |
| Consejo |
Voluntarios sin remuneración |
| Financiación |
Donaciones y subvenciones |
| Huella estimada |
Hasta el 70% de los sitios web |
| Propuestas de código |
Casi el doble que hace un año |
¿Por qué nadie paga por PHP (y el software libre en general)?
El software libre tiene un problema de incentivos conocido. Las empresas que más se benefician de un lenguaje son las que menos pagan por mantenerlo, porque el beneficio es difuso y el coste es concreto. Cada compañía prefiere que lo pague otra.
En el caso de PHP, el agravante es que el lenguaje sostiene productos que facturan mucho. Plataformas de comercio, gestores de contenido, sistemas internos de banca y administraciones públicas funcionan con código PHP. Ninguno de esos usuarios aparece en la lista de donantes habituales.
La comparación con la infraestructura física ayuda. Nadie espera que un puente se mantenga con donaciones voluntarias, porque el coste de su colapso es evidente y recae sobre quien lo usa. En el software, ese coste se reparte entre millones de personas y por eso nadie se siente responsable.
Una semana que pone el foco donde se debe
Los dos fallos publicados recientemente obligaron a una coordinación internacional en pocas horas. Cloudflare reportó millones de intentos de ataque, y la fundación ha dicho que no tiene evidencia de que se explotaran antes de la divulgación ni en sistemas ya parcheados.
Ese resultado es mejor de lo que cabía esperar y no debe tranquilizar demasiado. La respuesta funcionó porque hubo investigadores dispuestos, empresas que aportaron datos y una fundación que coordinó. Si cualquiera de esas piezas hubiera faltado, la historia sería distinta.
La otra lectura es sobre el calendario. Los fallos llevaban una década en el código, lo que significa que el problema no era nuevo: era invisible. La IA aceleró el descubrimiento y, con él, la necesidad de responder rápido.
Lo que cuesta mantener un lenguaje
Un lenguaje de programación no es solo un intérprete. Es documentación, pruebas, soporte de versiones antiguas, gestión de vulnerabilidades y una comunidad que responde preguntas. Todo eso consume tiempo, y el tiempo de las personas con criterio es lo que ninguna donación pequeña puede comprar.
Cuando la financiación es insuficiente, los efectos no aparecen como una caída inmediata. Aparecen como decisiones que se posponen: una revisión que se hace más superficial, un parche que tarda más, una propuesta que se queda sin respuesta. Con el tiempo, eso se convierte en deuda de seguridad.
La fundación ha dicho que PHP está «increíblemente infrafinanciado» para la dependencia que tiene. Es una frase incómoda dicha por quien la pronuncia, y es también la conclusión más honesta que se ha publicado esta semana.
Las empresas deben aportar a PHP
La primera medida es saber cuánto dependen del lenguaje. Muchas organizaciones no tienen inventario de su propia infraestructura y descubren que la mitad de sus sistemas críticos corre sobre PHP cuando hay un incidente.
La segunda es financiar. Una empresa que ahorra un equipo entero gracias a un lenguaje debería aportar una fracción de ese ahorro al proyecto que lo mantiene, sea con dinero, con tiempo de ingeniería o con infraestructura.
La tercera es participar en la revisión. Contribuir con código es útil y contribuir con revisiones de calidad lo es más, porque el cuello de botella está en evaluar lo que otros proponen.
Ninguna de las tres resuelve el problema de fondo, que es estructural. Y todas juntas convierten una dependencia invisible en una relación con contrapartidas, que es el primer paso para que el próximo fallo de una década se encuentre antes y se arregle con más gente de la que hoy hay disponible.
