Haikuports: Ban applications which ship a statically-linked web browser

[waddlesplash]

This is not yet an issue we really need to worry about; but, well, it probably will be eventually, so we should think about this now.

Essentially, this is about Electron-based applications, e.g. Slack, Spotify, WhatsApp, Atom, Visual Studio Code, etc. These applications do not use a system-wide browser component, but ship their own. This means that every new browser update due to vulns, bugfixes, etc. means that every single application which uses Electron must be individually updated, which is kind of a nightmare (here's a news article about it.) It also means that Electron apps tend to be about 50-150MB installed (and consume 1-2GB of RAM at runtime; but that's another issue.)

There are now attempts to port Qt WebEngine (#3040, etc.) which some "Electron-like" apps (OnlyOffice, etc.) use. This, I think, is OK, so long as we are using one QtWebEngine package for the whole system that we can update at once, not one per application. What will not be OK is maintaining web engines for every single application that wants to use them.

Thus, if we eventually have a proper Chromium port, Electron apps should be required to use the system provided one if they want to make it into HaikuPorts. (Actually I am tempted to suggest we ban Electron-based apps entirely, as IMO their bloat and overall UI/UX goes so far against the spirit of Haiku in a way that Qt and wxWidgets et al. do not. But this is perhaps a more controversial proposal, so I'll go with this for now.)

[waddlesplash]

CC @pulkomandy, @extrowerk, @alaviss, @fbrosson.

No hurry on this one, but your feedback will be appreciated.

[extrowerk]

While we cannot stop somebody to port things i am sure i will never invest any work in electron based software.
+1 from my side, no static webbrowser.

[alaviss]

+1, I'm against bundling of any kind, unless it actually makes sense.

(Actually I am tempted to suggest we ban Electron-based apps entirely, as IMO their bloat and overall UI/UX goes so far against the spirit of Haiku in a way that Qt and wxWidgets et al. do not. But this is perhaps a more controversial proposal, so I'll go with this for now.)

-1 for this one, or maybe we can establish a community-based _source_ repo (something like AUR, but for HaikuPorter) to host those recipes.

[pulkomandy]

Valid arguments, but I'm against banning apps.

Let's rather use HaikuDepot rating system for this. I hope I'll see many "your app is bloated and slow and vulnerable" comments there.

I think wx and Qt apps already go against the original Haiku spirit. They nowhere reach the integration level we aim for. But that's no reason for banning them.

Let's make better use of rating and featured packages to show our selling points. Let's still have these other apps available, as maybe second class citizen (as GTK would be on Windows or MacOS, for example), maybe with a little more effort integrating them.

If someone wants to do the work, I don't have an issue with these apps. We should however push whoever ports them to consider proper integration with the OS, and that probably means attempting to dynamically link the browser engine instead of bundling a copy in each app. Good luck to them.

[return]

I think that the maintenance and security concerns for bundled electron-based apps, sounds reasonable for just rejecting them from HaikuPorts. Unless they can be modified to use a dynamically linked version of our electron port (if we get one) then we should have some guidelines that discourage bundled electron-based software.

I would +1 for guidelines on discouraging bundled browser/electron apps in HaikuPorts, unless they can be modified to be dynamically linked.

-1 for a total ban. This sounds too extreme. I also dislike electron apps to some extent, but if someone is willing to follow the guidelines, port it and integrate it into HaikuPorts, I can't stop them but I won't maintain it either (without docs that is). To each to their own I guess.

[waddlesplash]

https://github.com/haikuports/haikuports/wiki/HaikuPorts-Policies