iekahVa5

> First of all, you should be compiling your own binary from the sources, otherwise you are blindly trusting that those binaries you download are built from the original source code, which may not be the case.

That's actually what I do, and it works well for me. I switched back to gentoo when I decided to do that, precisely when I realized that trusting that binaries match their source code was unjustified (I had already a decade of using gentoo, so it was not a problem for me).

I also switched back to chromium, for that reason. Firefox is great, but it won't allow me load an extension from the FS permanently. All the extensions I use nowadays are loaded from sources (unpacked extensions, as chromium is calling them), after an inspection from me.

Of course, I haven't read the code of _all_ the programs I'm running on my system, so it's not perfect security. I'm still confident this is a better level of trust than running binaries.

A side effect of that is that since I actually _do_ read a lot of code from the programs I use, I learn a lot, and it often happens that I change code of programs I'm running to fit my need (the portage system of gentoo make it easy to write your own ebuilds and integrate your changes in your package manager).

Doing so require specific hardware, though, as if you're not careful on what hardware you take, you'll probably need binary blobs to use it.

There is still a security problem I need to solve. Some programs (well, chromium, mainly) easily take 6 to 8 hours to compile. So I usually just lock the version to a stable one and update every month. This may be a problem if a security patch is released.

That's the one I would have mentioned as well.

When you release something as FOSS, you think people will offer contributions to your code. What you get instead is tons of issues on your issue tracker without anyone trying to solve their problems and taking the issue tracker as some sort of commercial support. If you assume the role of maintainer, you will get more work from sharing your code, not less. And most of that work will be to try to figure people problems because they didn't try to solve them themselves as it's easier to just open an issue and wait. Most of them won't even have looked at your code.

This is easily solved, though : just don't provide an issue tracker (or disable it if there's one, like on github). This may sound harsh, but if what you have to offer is useful, better disabling the issue tracker than not releasing it. People can still fork your code and fix their problem, and you can then merge it in your code. Not every developer is a maintainer.