|
| 1 | +<!DOCTYPE html> |
| 2 | +<html lang="en"> |
| 3 | + <head> |
| 4 | + <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> |
| 5 | + <title>A word about complexity</title> |
| 6 | + <link rel="icon" type="image/png" href="/img/favicon.png"> |
| 7 | + <link rel="stylesheet" href="/style.css"> |
| 8 | + </head> |
| 9 | + <body> |
| 10 | +<main> |
| 11 | + <h1>A word about complexity</h1> |
| 12 | + <i>Written on 2025-09-14 by Rodrigo Arias Mallo</i> |
| 13 | + <p> |
| 14 | + After spending some time dealing with problems derived from the complexity of |
| 15 | + the web, I would like to write something about it. |
| 16 | + </p> |
| 17 | + <p> |
| 18 | + It has come to my attention that the GPL and other free-software licenses |
| 19 | + don't seem to be enough to protect their core idea: "[to] guarantee end users |
| 20 | + the freedom to run, study, share, or modify the software". There is another |
| 21 | + barrier that prevents users from being able to modify the software: |
| 22 | + <strong>complexity</strong>. |
| 23 | + </p> |
| 24 | + <p>An individual or small group of individuals with a common goal of modifying |
| 25 | + a piece of software should be able to do it. However, this doesn't seem to |
| 26 | + work in practice. For example, despite Chromium being licensed with a |
| 27 | + permisive license, people cannot just fork it and reintroduce support for |
| 28 | + Manifest V2 to continue to support it on their own, to be able to use |
| 29 | + ad-blockers as most people would want. The cost of maintaining a working fork |
| 30 | + is just too high because the codebase is too complex. The right to modify the |
| 31 | + source code doesn't seem to be enough. |
| 32 | + </p> |
| 33 | + <p> |
| 34 | + One of the first changes that I introduced when I started to maintain Dillo |
| 35 | + was to try to limit the complexity of the browser to guarantee that we don't |
| 36 | + accidentally arrive at the same situation. So I decided to distribute the |
| 37 | + releases in a single floppy disk, which bounds the extension of the source |
| 38 | + code to 1.44 MB. This is far from being perfect, but it works in practice for |
| 39 | + our particular case and is easy to measure. If we eventually become evil |
| 40 | + (hopefully not), another party could fork the code and continue without |
| 41 | + requiring a gigantic team of developers to maintain it. |
| 42 | + </p> |
| 43 | + <p>A side effect of not being able to extend the software to implement all |
| 44 | + the features you want, is that you eventually make it interoperable with other |
| 45 | + programs. So, instead of having to enforce the UNIX philosophy ideas of "doing |
| 46 | + one thing only" and "write programs that work together", you already get them |
| 47 | + as a side effect. If you try to include support for additional features in the |
| 48 | + same program, it just doesn't fit. So you are forced to interoperate with |
| 49 | + already existing software if you want to add support for it. For example, |
| 50 | + instead of adding support to display videos or audio in Dillo, we added the |
| 51 | + support to open them in external programs. This keeps the browser simple. |
| 52 | + </p> |
| 53 | + <p> |
| 54 | + If this rule continues to prove to be effective, it would be ideal if it could |
| 55 | + be added to a similar license to the GPL so that it guarantees that a given |
| 56 | + program cannot grow outside of a given reasonable limit. It would keep the |
| 57 | + software permanently small so that it always remains hackable. |
| 58 | + </p> |
| 59 | +</main> |
| 60 | +<footer> |
| 61 | +<a href="../index.html">← Back</a> |
| 62 | +</footer> |
| 63 | + </body> |
| 64 | +</html> |
0 commit comments