Yo: Konqueror fue forkeado para hacer WebKit. Chrome es un fork de WebKit. Es asi ?

No del todo. Hay algo correcto en esa cadena, pero también hay imprecisiones importantes.

Lo que es correcto

KHTML → WebKit: Sí. Apple tomó KHTML (el motor de renderizado del navegador Konqueror, desarrollado por KDE) y lo forkeó en 2002 para crear WebKit. Eso es correcto.

Lo que es impreciso

WebKit → Chrome: No exactamente. Google tomó WebKit y creó un fork llamado Blink en 2013. Chrome usa Blink, no WebKit directamente.

Entonces la cadena correcta es:

KHTML (Konqueror/KDE)
    ↓ fork (Apple, ~2002)
WebKit (Safari)
    ↓ fork (Google, 2013)
Blink (Chrome, Opera, Edge, etc.)

Detalle importante

  • Safari sigue usando WebKit hasta hoy.
  • Chrome, Edge (desde 2020), Opera y Brave usan Blink.
  • Firefox usa su propio motor, Gecko, independiente de toda esta familia.

Una curiosidad: cuando Apple forkeó KHTML, la relación con los desarrolladores de KDE fue bastante tensa al principio, porque Apple tardó mucho en compartir sus cambios de vuelta, lo que iba en contra del espíritu del open source.

Tenés toda la razón en el análisis, y el diagrama muestra exactamente esa realidad. Te desgloso todo:


La situación real de los motores

Hay literalmente tres motores que dominan la web moderna:

Blink (Google, 2013): Chromium no usa WebKit, Gecko ni ningún otro motor ajeno — es su propio stack. Pero atención: Blink en sí es un fork de WebKit, del que Google se separó en 2013 por diferencias técnicas con Apple. Chrome, Brave, Edge, Opera, Vivaldi, Arc… todos son Chromium por dentro.

Gecko (Mozilla): base de Firefox y todos sus forks — Waterfox, LibreWolf, Tor Browser, Zen Browser. Pale Moon tiene además su propio fork de Gecko viejo llamado Goanna.

WebKit (Apple): Safari, GNOME Web, y curiosamente todos los navegadores en iPhone (Chrome, Firefox incluidos), porque Apple obliga a que todo lo que corra en iOS use WebKit.


Sobre QtWebEngine y Falkon

Falkon está construido sobre QtWebEngine, que es un wrapper del núcleo de Chromium. Así que sí, técnicamente Falkon es Chromium por debajo, con una interfaz Qt encima. Otros navegadores que usan QtWebEngine: qutebrowser (orientado a teclado, estilo Vim), Otter Browser (recrea la interfaz clásica de Opera 12), y Konqueror de KDE.


Sobre los “nuevos” independientes

Ladybird es un navegador completamente nuevo con su propio stack de motor, gobernado por una fundación sin fines de lucro. No reutiliza Chromium, WebKit ni Gecko. Su alpha para Linux y macOS está prevista para 2026 y no usan código de Blink, WebKit, Gecko ni ningún otro motor existente.

Además de Ladybird existe Servo, un motor experimental escrito en Rust, concebido como reemplazo alternativo a Blink, WebKit y Gecko, ahora bajo la Linux Foundation.


La conclusión

A pesar de la gran cantidad de nombres, hay sorprendentemente pocas opciones bajo el capó. La familia Apple WebKit y Google Blink dominan, seguidas por Gecko de Mozilla y su fork Goanna, y después jugadores menores prometedores como Servo y LibWeb de Ladybird.

Tu resumen es prácticamente perfecto: en la práctica existen 3 motores reales (Blink, Gecko, WebKit), y el resto son forks o wrappers. Lo que diferencian Chrome de Brave, o Firefox de LibreWolf, es mayormente la interfaz, la configuración de privacidad por defecto, y algunas funciones extra — no el motor que renderiza las páginas.

Muy buena pregunta, la distinción es importante. Y sí, el paralelo con Linux es casi perfecto.


Fork vs Wrapper

Un fork es cuando tomás el código fuente de un proyecto, lo copiás, y empezás a modificarlo de forma independiente. El resultado comparte historia con el original pero puede divergir con el tiempo. LibreWolf es un fork de Firefox: agarraron el código de Firefox, le cambiaron configuraciones, sacaron telemetría, y lo compilan ellos mismos. Brave es un fork de Chromium: modifican el código fuente directamente antes de compilar.

Un wrapper es diferente: no modificás el código del motor, simplemente lo usás como librería o componente ya compilado, y construís tu interfaz encima. Falkon no toca el código de Chromium — instala QtWebEngine como dependencia y construye la UI alrededor. Es como la diferencia entre remodelar una casa desde los cimientos versus decorar un departamento que alquilás.

En la práctica la línea puede ser borrosa: Brave modifica Chromium antes de compilar (fork real), mientras que Falkon usa QtWebEngine ya compilado (wrapper). Pero ambos terminan corriendo el mismo motor Blink por dentro.


El paralelo con Linux es excelente

Es casi idéntico. Los “motores” del mundo Linux serían los sistemas base realmente independientes:

Debian → Ubuntu, Linux Mint, Pop!_OS, Kali, Raspberry Pi OS… cientos de forks.

Arch → Manjaro, EndeavourOS, Garuda, CachyOS…

Red Hat / Fedora → CentOS, AlmaLinux, Rocky Linux… (y RHEL es en sí mismo un fork de Fedora hacia “arriba”)

Alpine → muy usado en contenedores Docker, pocos forks directos pero muy influyente.

Void Linux → independiente, usa runit en vez de systemd, tiene su propio gestor xbps.

NixOS → completamente distinto en filosofía, declarativo, reproducible.

Gentoo → independiente, compilás todo desde fuente. ChromeOS deriva de aquí (Chromium OS).

Slackware → el más viejo aún vivo, casi sin forks relevantes hoy.

Y así como en los navegadores hay un engine que renderiza las páginas, en Linux el “motor real” es el kernel — que todos comparten. Lo que diferencia las distros es el gestor de paquetes, el init system (systemd vs runit vs OpenRC), las decisiones de configuración por defecto, y el ecosistema de software incluido. Igual que Chrome vs Brave: mismo motor, distinta capa encima.

La diferencia más importante entre el mundo Linux y el de los navegadores es que en Linux hay muchas más bases verdaderamente independientes, mientras que en navegadores la consolidación es brutal: básicamente todo convergió en tres motores, dos de los cuales (Blink y WebKit) comparten ancestro común. Ladybird y Servo son los primeros intentos serios en años de romper esa concentración.

Yo: Y pero KHTML no tenia GPL ?

Exacto, muy buena observación. KHTML estaba licenciado bajo LGPL (Lesser GPL), no GPL estricta.

Por qué eso importó

La LGPL es más permisiva que la GPL. Permite que código propietario enlace o use la biblioteca sin tener que liberar todo el código propio. Eso fue clave para Apple, porque:

  • Con GPL pura, Apple hubiera estado obligada a liberar todo el código de Safari/WebKit como open source.
  • Con LGPL, podían usar KHTML como base e incorporarlo en un producto mayormente propietario, siempre que publicaran los cambios al propio motor.

El problema real que hubo

Aunque la LGPL lo permitía, Apple igual fue criticada porque:

  1. Tardó mucho en devolver sus cambios a la comunidad KDE.
  2. Los parches que enviaban eran difíciles de integrar (grandes diffs sin contexto, código mezclado).
  3. Los desarrolladores de KHTML en un momento dijeron que les resultaba más fácil reimplementar features por su cuenta que integrar lo que Apple mandaba.

Conclusión

La LGPL fue lo que hizo posible que Apple forkeara KHTML legalmente sin abrir todo su sistema operativo. Si hubiera sido GPL pura, el fork hubiera sido mucho más complicado legalmente, o directamente Safari hubiera tenido que ser open source.

Yo: uso falkon

¡Buena elección! Falkon tiene una historia interesante y está directamente relacionada con todo lo que estuvimos hablando.

Qué es Falkon

Falkon es un navegador web desarrollado por KDE (sí, los mismos de Konqueror). Originalmente se llamaba QupZilla y fue renombrado a Falkon cuando KDE lo adoptó oficialmente en 2018.

Motor de renderizado

Usa QtWebEngine, que es el wrapper de Qt sobre Blink (el motor de Chrome/Google). Entonces la cadena completa sería:

KHTML (Konqueror/KDE)
    ↓ fork (Apple)
WebKit
    ↓ fork (Google, 2013)
Blink
    ↓ wrapper Qt
QtWebEngine
    ↓
Falkon

Hay algo casi poético ahí: KDE terminó usando el bisnieto de su propio motor.

Por qué es rápido

  • Blink es un motor muy optimizado (es el mismo de Chrome).
  • Falkon es mucho más liviano que Chrome/Chromium porque no tiene todo el ecosistema de Google encima.
  • Está construido con Qt, que es eficiente y bien integrado en escritorios Linux, especialmente KDE Plasma.

Desventaja principal

Al usar QtWebEngine, va un poco rezagado en versiones respecto a Chromium, lo que a veces puede implicar vulnerabilidades de seguridad sin parchear por un tiempo.