理论上当然是可以共享的，Linux 包管理就做得很好
"很好“的意思是现在我平常使用的唯一 Electron 程序——VSCode 被拆开了，然后就如楼上几位所预料的一样，出现了这种结果：
https://www.archlinux.org/packages/?sort=&repo=Community&q=electron&maintainer=&flagged=点进去会发现虽然 Electron 感觉上无处不在，依赖这几个”共享“的 Electron 包的包两只手就能数的过来，最大用户是 VSCode 和 Atom，以及 Keybase 、Signal 、Riot 等几个互联网应用。并且 VSCode 和 Atom 依赖的版本都不一样——也就是说如果我要同时装 VSCode 和 Atom，还是要装俩 Electron 。假设你装 8 个 Electron 应用，可能这 6 个版本的 Electron 还是都会出现在你的硬盘里（虽然 Arch 的软件源里面并没有 8 个 Electron 应用可以给你装 ...）
尽管如此，相比于 8 个应用需要装 8 份运行库，现在装 8 个应用需要装 6 个运行库，还可以以包管理的方式组织起来，我仍然认为这是一种严格的提升。但是显然这并不直接解决楼主的问题，重要的是这种现象给咱们的启发，我的观察如下：
* Linux 生态系统受 Electron ”污染“ 较少。
* “互联网”应用更倾向于使用 Electron——上面列举的几个 Linux 下使用 Electron 的应用，都是互联网应用或有互联网背景。Linux 生态本身互联网应用较少，所以 Linux 下 Electron 比较少。同理使用 Electron 的应用肯定是桌面应用，Linux 桌面应用也少。
* 要想共享运行时，用户环境必须有一个可信任的、被公开承认的中心全局软件库。Windows 和 Mac 并非没有这样的软件库，这种软件库一直在起作用——MSVCRT 、.Net 运行时、DirectX 、ObjC 运行时、Cocoa 等都是通过这些系统中的中心软件库分发的，但是很明显在这些专有操作系统中，中心软件库仅仅对第一方软件实际有效。Linux 虽然看起来做得更好，但是软件库是由发行版管理，当讨论“Generic Linux”的时候，中心软件库（具体的包管理机制）是一个“存在但不可用”的状态。虽然很多软件并不鸟所谓“Generic Linux”，而是只做 Debian 、CentOS 等主流发行版，并非每个发行版的软件库都能保持最新，因此很多软件在 Linux 上分发时依然将 Electron 打包进去了（ Arch 把 Electron 从 VSCode 中拆出来是社区行为）。
* 这里还要提两个特例，第一是 Linux 的包管理方案并非完美，比如 Arch 一个臭名昭著的问题：
https://old.reddit.com/r/archlinux/comments/6jce9x/pandoc_minus_the_new_750mb_haskell_nonsense Electron 一个开发 GUI 程序的库，不过 150M，pandoc 一个 native CLI 程序却要装 350M 的额外库。第二是各种编程语言的包管理机制，就算是做得最烂的，单独来看相比于系统级的软件管理还是要优雅太多。
* 开源软件一般都能实现运行时的共享。开源软件的开发模式一般是核心团队维护中心仓库，所有人在不同的环境下工作（包括核心团队的环境也是不一样的），中心仓库只维护软件本身不维护依赖，这种开发模式决定其对环境要求不能太苛刻。开源也决定了就算开发团队不会做这个事，社区也可以帮忙拆出来。以上这几点都说明，如果软件是开源的，那么共享运行时本来就不是什么问题。
* 非开源软件一般倾向于不共享运行时。非开源软件的使用价值是绝对首位，开发者会选择把运行时和软件一起分发来最小化开发成本，以及最小化用户可能的破事。对于免费软件来说可以减少支持压力，对于收费软件还可以最大化收入。非开源软件的开发者环境一般比较固定，源码换了一个编译器版本就 build 不过是常有的事——并且就算内部发现有此类问题，一般解决方案是统一环境而不是完善项目。另外对非开源软件进行修改技术上和法律上都有问题，所以开发者不做运行时共享，其他人基本没法做。至于用户吃多少屎，那就不是开发者的事了。
非开源软件能做到什么程度？我昨晚刚看了这个 talk： <amp-youtube data-videoid="2YXwg0n9e7E" layout="responsive" width="480" height="270"></amp-youtube>?t=1723 在这个链接的时间戳，这位曾获得奥斯卡 Sci-Tech 奖的 C++ 程序员自豪地说道：为了解决客户的兼容性问题，他们有个人花了半年时间把 boost 库中的所有 boost 命名空间改名成 hboost，当然这就意味着他们还必须分发一份根本没法拆出来的 boost 。
但是由于上述的原因，就算他们不这么改，也不意味着这个 Boost 的冗余可以被消除。我系统里除了包管理器装的版本之外，还有至少 4 份 libpython 和 libQt5Core —— Electron 并不是我系统中冗余最多的运行时，Python 和 Qt 才是 ... 可见并不只是 Electron 的问题。
虽然我认为 Electron 这个工具的原罪不可忽略，但是我觉得依赖管理的问题还是要和用户界面的问题分开来谈——不仅仅是 Electron 、Python 或者 Qt 。如果你用 Mac，那在你的 /Applications 文件夹下，大概率躺着不少于十个 Sparkle.framework
在我看来，对于闭源软件来说，共享运行时一般是特例，或者说只有不得不共享的（比如 .Net, DirectX 等）才会共享。所以我对楼主的想法的看法是：开源软件已经实现，闭源软件没这传统。
关于上面的几楼胡逼内容：aardio 或者 oidraa 什么的不仅不解决根本问题，更连楼主的眼前问题也解决不了。楼主所举的几个软件都有跨平台需求，并且都是在各平台都有带量用户的带项目（不存在“支持那百分之零点几市场的操作系统有毛用”的问题）。
而根本问题则是 5L 所说，不同程序之间代码共享的问题，该问题广泛地存在于各类开源和闭源软件，GUI 程序和非 GUI 程序中，一个新的 Electron 并不能解决这个问题。