Para muchos de vosotros, está bastante claro que deberíamos ofrecer Vivaldi bajo una licencia de código abierto.
El navegador está disponible de forma gratuita, ganamos dinero con las búsquedas y acuerdos con socios…no tendría que haber ningún problema en dar acceso al código fuente y permitir que personas externas ayudaran a desarrollarlo, ¿verdad?
Entendemos esta postura, y esta es una cuestión que se debate de manera interna de forma recurrente, ya que muchos de nosotros somos defensores y usuarios del software de código abierto.
Sin embargo, como con todo, el asunto se vuelve más complejo una vez que empiezas a analizarlo.
Una parte de código abierto, una parte de código cerrado
Antes de empezar, recapitulemos un poco.
El navegador de Vivaldi tiene tres capas principales.
Como muchos de vosotros sabéis, utilizamos Chromium como los cimientos de nuestro navegador.
Sobre Chromium, hay código backend C++ para dar soporte a nuestras funciones, como el Bloqueador de anuncios y las Notas.
Estas dos capas sostienen nuestra interfaz de usuario (UI), que se presenta de dos formas:
- En la UI de la versión de escritorio utilizamos sobre todo HTML+CSS+JS.
- En Android, la UI está implementada en Java, y proviene mayormente de la UI Java incluida en Chromium (la licencia del código Java de Chromium no nos obliga a publicar los cambios que hagamos).
Chromium tiene una licencia de código abierto, y publicamos todos los cambios que le hacemos para nuestra UI y nuestras funciones. También publicamos todo el código backend C++ de las funciones, como si fuera parte de los cambios hechos a Chromium. Esto facilita el proceso interno, ya que nos permite agruparlo todo en uno (Chromium y nuestro código C++).
Puedes encontrar una copia de este código en nuestra página web. Los cambios se publican bajo una licencia BSD y podrás encontrar todos los detalles en los archivos README y LICENSE.
Vivaldi también contiene código de terceros. Puedes encontrar las licencias de esta parte del código en el paquete fuente, y en el propio navegador, si abres vivaldi://credits.
De las tres capas, sólo la capa de la interfaz de usuario es de código cerrado. Lo cual se traduce en que aproximadamente un 92% de Vivaldi es el código abierto de Chromium, un 3% es código abierto nuestro, y un 5% es el código cerrado de la UI.
La marca Vivaldi
Si es tan poco lo que separa a Vivaldi de una licencia de código abierto, ¿por qué no lo publicáis?
La UI de Vivaldi es lo que hace único nuestro navegador, y es por ello la parte más preciada del código.
No hemos publicado el navegador bajo una licencia de código abierto, y sólo lanzamos versiones en las que recurrimos a la ofuscación. En parte para mejorar el rendimiento, pero también como primera línea de defensa, para evitar que otros cojan el código y diseñen un navegador similar.
¿Y por qué deberíamos temer las posibles bifurcaciones o proyectos derivados del nuestro?
Esta es una cuestión subjetiva y no espero convencer a nadie, pero nuestro punto de vista es el siguiente:
Este tipo de proyectos son básicamente la ‘gracia’ del software de código abierto. Coges el código de otros, lo modificas y si consigues hacer algo bueno, tú recibes reconocimiento por lo que has añadido, el proyecto del que sacaste el código recibe reconocimiento por ser el proyecto original, y a lo mejor incluso deciden incorporar tu trabajo y todo el mundo contento.
Pero como he dejado caer antes, Vivaldi es más que un código. También es una marca, y marcas asociadas, por lo que cualquier proyecto derivado del nuestro tendría que ser registrado como un producto nuevo bajo una marca diferente. Esta es la razón por la cual Chrome y Chromium no son lo mismo.
En ese momento, el nuevo producto se convierte en un competidor inmediato sin haber tenido que llevar a cabo el trabajo técnico que requiere ese estatus (aunque aún quedaría la comercialización y el marketing).
Si hablamos de proyectos grandes que llevan años en marcha, o que tienen suficiente renombre, lo más probable es que la gente no preste atención a un proyecto derivado.
Sin embargo, Vivaldi es aún pequeño y se nos podría hacer sombra fácilmente, lo cual nos hace vulnerables, y no sólo en términos de ganancias.
Si un nuevo proyecto basado en nuestro código implementara funciones que fueran en contra de nuestra ética (perjudiciales para los derechos humanos o el medio ambiente, por ejemplo), aunque no estaríamos asociados al autor de esas funciones de ninguna manera, afectaría a la moral de nuestro equipo. Y aunque no seríamos responsables de ese proyecto, es probable que se nos mencionara junto a él, lo cual podría afectar a nuestra reputación.
Recurrir a la ofuscación y mantener la UI de Vivaldi como código cerrado nos permite olvidarnos de estos problemas, aunque está lejos de ser una solución perfecta. En el mundo empresarial, sentimos que tenemos que tomar decisiones que minimicen la incertidumbre, aunque sea sólo por respeto a nosotros mismos, como empleados.
Los procesos de código abierto son demandantes
Hay otra razón más pragmática por la cual no nos hemos decantado por una licencia de código abierto. Una parte atractiva sería sin duda el poder recibir aportes de las magníficas personas que nos apoyan. Pero incluso esto tiene su lado negativo, dado el tamaño de nuestro equipo. Los procesos de código abierto requieren que se revisen las aportaciones y se mantenga una comunicación con los desarrolladores de las mismas.
Todo ello requiere tiempo, y dadas nuestras limitaciones, no estamos seguros de que los beneficios fueran a ser mayores que los inconvenientes. Por ahora, sentimos que es más productivo centrarnos en diseñar el navegador más personalizable.
¿Y los beneficios en términos de seguridad?
Los aspectos relacionados con la seguridad de nuestro navegador están en mayor parte integrados en el código Chromium, pero también hay código relevante en la UI de Vivaldi. Si publicar estas partes específicas relacionadas con la seguridad te haría confiar más en Vivaldi, háznoslo saber y lo tendremos en cuenta a la hora de decidir qué parte del código incluimos en los paquetes que hacemos públicos.
¿Y qué pasa si Vivaldi desaparece?
Es una preocupación válida. Muchos de nosotros aún tenemos presente la frustración de cómo el Opera basado en Presto no pudo seguir existiendo después de que Opera pasara ser un proyecto basado en Chromium. Yo mismo dediqué mucho tiempo a trabajar en el Opera basado en Presto, haciendo mejoras y arreglos, y sí, me da la impresión de que si hubiera sido un proyecto de código abierto podríamos haberlo mantenido con vida y no se habría echado a perder.
¿No sería entonces buena idea convertirse en un proyecto de código abierto? Sí, sería estupendo. En esto todos los miembros del equipo de Vivaldi estamos de acuerdo. Por otro lado, estamos creciendo y no somos pesimistas sobre nuestro futuro. Aunque tenemos esta cuestión en mente, no es algo urgente por ahora.
No hay vuelta atrás
Esta es el argumento más importante, y una de las claves del asunto.
No puedes “probar” a ser de código abierto y después volver a ser un proyecto de código cerrado si la prueba no sale bien. El código que se publica con una licencia de código abierto es irrecuperable. Lo único que podrías hacer es trabajar en que el código publicado se volviera obsoleto, lo cual requiere muchísimo tiempo. Es por eso que, como empresa, no estando seguros de qué significaría el cambio, lo mejor es no probarlo por el momento. El código abierto es genial, pero este es uno de los aspectos difíciles que supone.
Modificar Vivaldi para hacerlo aún más personalizable
Si no te interesa ninguno de los argumentos que hemos presentado hasta ahora, y lo único que te gustaría es poder modificar el código para personalizar Vivaldi a tu gusto, te gustará saber que esto es algo que ya puedes hacer con la versión de escritorio.
Puedes hacer ingeniería inversa y modificar el código ofuscado, editando directamente el código javascript minimizado.
Este proceso es más fácil que con otros navegadores, que requieren una fase de compilación para poder aplicar cambios.
Nuestra licencia no permite de manera oficial que se haga, pero lo aceptamos y dejamos que nuestros usuarios compartan estas ediciones de código en nuestro foro.
¿Debería Vivaldi ser de código abierto?
Como esperamos que hayas podido ver, no es una decisión fácil.
Habiendo tanto argumentos a favor como en contra, por ahora estamos contentos con la solución a la que hemos llegado: ofrecer un software gratuito, que incluye una gran porción de código abierto y sólo una parte limitada (pero editable) de código cerrado.
Esta será nuestra posición, mientras sigamos pensando que merezca la pena proteger el aspecto de Vivaldi y la identidad de nuestra marca, pero es algo que nos seguiremos planteando. (¿Queréis saber un secreto? Negaremos haber dicho esto, pero en verdad es algo que nos haría ilusión).