| My concerns with ostensibly privacy-focused Firefox forks: * Needing to constantly monitor whether the fork is being actively maintained, or if it's a vanity project which abruptly stops/slows down updates when its owner/principal contributors lose interest. * Needing to constantly monitor if the fork is using the latest official Firefox builds to make sure that it's also getting the latest security updates. * Not being readily able to see a complete humanly understandable (meaning not just comparing git versions) list of changes that the fork makes to the official build. * Not knowing the reputation of the developers behind the fork. In sum, I basically trust Mozilla more than I do $random_fork_developer, so I use the official build and carry out my own tweaks, but I am always on the look out for more tweaks, which is why I'd appreciate if lists of privacy tweaks custom builds do were more transparently shared. |
The two closest build systems I’ve seen to getting it right: Nix (closest) and FreeBSD ports.
I’ll use the i3 window manager as an example. There are plenty of forks of i3 out there (example: adding space between windows, rounded corners, i3bar mods, etc). They’re each packaged and published as separate packages! You can’t compose them even though many of their changes are compatible. This leads to packages like i3-gaps-rounded.
What I really want out of a package manager is “patch support” - where I can publish, discover, share, and consume patches on top of the OSS I use.
Nix gets really close to this. I haven’t invested enough time in learning Nix yet, but it’s on my bucket list. Currently I use FreeBSD and use their ports collection for i3, and put all of my patches in the patch directory there. FreeBSD will apply the patches in order and then build the package for me.
I’m not sure exactly where I’m going with this rant beyond: I wish OSS package management adopted less of a producer-consumer relationship and more of a peer relationship when it comes to source code management and builds.