Barrier has been abandoned quite awhile ago. Its successor is supposed to be InputLeap, and although their GitHub repo is very active, they have yet to make a release.

I didn’t even know that Synergy provided a “community” version of their app until very recently. I’ve paid for a license many years ago, so I’ve been using their 1.1x versions, which for better or worse, are still maintained along with the 3.x branch (which I’ve tried using but could never make it work, which is for the best because the fact they pivoted their UI to electron-based also left a bad taste in my mouth).

Edit: also, if I understand correctly, Synergy’s latest versions on the 1.x branch borrows a lot from InputLeap.

Not a variant. Read their README. It IS Synergy, they’re renaming the open-source / community version to that, while Synergy will remain the commercial product built out of that.

This. It’s not as simple to get it working as it is on non-free OS’s, but with rclone I can get on Linux pretty much the same functionality I get from (eg.) Google Drive on Windows, including have most of the drive with on-demand access (meaning files are not stored locally, but downloaded / uploaded as needed) with a few specific folders synced for offline use. Since it supports a lot of storage services, I suppose it shouldn’t be that different to set it up the same way with Proton Drive.

Here. Tl;dr: He took it private for reasons, should bring it back in a “build it yourself” form later.

Thank you for digging this out. Turns out it’s even worse than what I gleaned from my surface-level take.

This sounds like dev sour grapes but what the company was asking them to do seems better from the customer pov and for cyber security I’m general.

As a developer myself (though not on the level of these guys): sorry, but just, no.

The key point is this:

[…] we did not issue CVEs for experimental features and instead would patch the relevant code and release it as part of a standard release.

Emphasis mine. In software, features marked as “experimental” usually are not meant to be used in a production environment, and if they are, it’s in a “do it at your own risk” understanding. Software features in an experimental state are expected to be less tested and have bugs - it’s essentially a “beta” feature. It has a security bug? Though - you weren’t supposed to be using it in a security-sensitive environment in the first place, it sounds perfectly reasonable to me that it should be addressed in a normal release as opposed to an out-of-band one.

We can argue if forking the project is or isn’t extreme, but the devs absolutely have good reason to be pissed. This is typical management making decisions without understanding technical nuances and - from what is being told by the devs - not talking it through before doing it.