Why did Barrier fail?

TL;DR: Barrier is dead; use Deskflow if you like experimenting and use Synergy if you need reliability.

Barrier (old fork) is now abandoned

Barrier is no longer an active project. That is not a controversial statement. It is a fact.

The GitHub repository is stagnant. Pull requests sit unreviewed. Issues pile up. There is no engagement from maintainers who refuse to archive the project.

What makes it sad is that developers still show up and try. They submit patches. They report bugs. They ask for help. And no one responds (apart from me, guiding them back upstream).

It wastes time. It creates the false impression that changes are possible, when the project has already stalled.

If you're looking to contribute to cross-platform input sharing, your energy is better spent elsewhere. Deskflow, the community upstream project, is active. It is fast-moving. It is unpolished. But it's what the community wants.

Changing the hello message doesn't change the protocol

One of the more confusing legacies of Barrier is its divergence of identity without divergence of implementation. To this day, we see developers struggle with protocol confusion because Barrier reports itself differently despite functioning identically to Synergy 1.x.

The message it sends during the initial connection handshake (the hello message) is different. This wasn’t paired with an actual protocol update. This means client/server mismatches became harder to debug and interoperability fractured... all without technical benefit.

When we introduced Deskflow as an open development community, we heard frequent confusion from developers and users alike.

Barrier did not evolve the protocol. It simply renamed it.

Anyway, that's why Deskflow now supports both Synergy and Barrier protocols (even though they're really exactly the same thing).

Lack of technical depth

The maintainers of Barrier took on a complex cross-platform codebase (built in C++, tightly integrated with system-level hooks, networking layers, and OS-specific quirks) mostly without the benefit of prior involvement. Their commits rarely addressed deeper architectural debt or long-standing bugs.

Clipboard sync remained unreliable (though they claimed it was "supported"). Modifier keys broke on macOS. Multi-monitor setups failed silently. Platform edge cases accumulated.

Releases slowed, then stopped. Pull requests went unmerged. Core contributors vanished. The project flatlined.

Input Leap: The fork of the fork

Input Leap emerged later, as a continuation of Barrier, with more active maintenance and greater intent to modernize. It deserves credit for taking some of the work further. But in many ways, it inherited the same foundational compromises and confusion.

What began as a movement for "de-commercialized Synergy” instead yielded years of fragmented efforts and unmet expectations.

Maintainer disputes and stalled progress

Part of what stalled Barrier, and later affected Input Leap, was not just technical debt, but friction among maintainers.

The original Barrier repository was owned by a user known as walker0643. Over time, key contributors emerged with the motivation and skill to push the project forward, most notably p12tic, who drove the bulk of meaningful development.

But walker0643 never transferred administrative control or shared full permissions. As a result, maintainers could not cut releases, manage issues, or merge critical pull requests without bottlenecks. Contributors were forced to work around the repo owner instead of with them.

The community fragmented again. Input Leap was created as a workaround, a fresh fork, sadly with the same technical debt of the old Synergy fork. It had better intentions, but the damage was already done. The cycle of divergence and duplication continued.

How Deskflow took root

While Barrier and Input Leap faltered, a different path forward began to form: one built not on branding or ideology, but engineering clarity. That path was Deskflow.

The project started quietly, led by Chris Rizzitello, a long-time contributor who had seen firsthand where Barrier and Input Leap fell short. Chris wasn’t looking to create “yet another fork.” He wanted to build the definitive upstream, a single source of truth. Deskflow is a new take with a focus on solid development principles and long-term maintainability.

Chris pulled together the strongest parts of the fork-ecosystem (patches from Barrier and improvements from Input Leap) while contributing deeply himself, particularly in modernizing the build system with CMake and refining the Qt-based UI. He also began tackling issues that had gone ignored for years, especially the neglected Qt GUI originally developed many years ago by Volker Lanz (legendary Qt developer and original author of the KDE Partition Manager).

Importantly, he didn’t work alone. Deskflow grew as a hacker-friendly transparent community, attracting contributors who cared more about fixing things than debating them. This wasn't just a community migration. It was a different universe.

Thanks to Chris’s stewardship and the community’s input, Deskflow has evolved rapidly over the last year. It now functions as the proving ground for ideas that will one day make their way into Synergy itself.

Why is Synergy even involved?

I honestly never planned to re-engage with the community in this way. Triaging issues and working on PRs with volunteers you never meet in person... can be rough sometimes. Employees on the Synergy team repeatedly complained about how difficult it has been to work with the community on things like PRs and managing the issue tracker... it has always been a huge point of contention.

For the longest time, I thought that pure customer driven development was the way forward. I was wrong. Red Hat proved me wrong. More specifically, Peter Hutterer (better known as whot) showed me that disengaging from the community was a mistake. He began his work on libei with Synergy in mind (as of writing this Synergy is mentioned several times in the readme doc) but implemented his new library in a Synergy fork, which impacted customers. Why? Because he figured implementing the change in the most active community would be best. It goes to show, the code doesn't always speak for itself, you need a hive of activity and discussion around it to be seen as "active". Ironically, disengaging with the community negatively impacted customers. This is a lesson I will not forget any time soon.

Honestly, we watched this unfold from the sidelines for a while... forks of forks, drama over repo ownership, half-baked UIs, bugs that kept coming back like they were immune to patches. It was frustrating, but also kind of fascinating.

People in those communities kept telling us Synergy was “the past” but the funny thing is, the past kept working, kept being developed quietly without the community drama. Meanwhile, all these forks were supposed to be cleaner, freer, better. In practice? They just made everything more confusing.

So why did we get involved?

Because Deskflow wasn’t just another fork. It was different. Chris wasn’t chasing brand clout or trying to rewrite history: he just wanted working software again. He started fixing the real problems from his perspective as an enthusiast, not as a customer. This was a journey that we started together, as a fully equal partnership.

We didn’t take over. We didn’t try to "Synergy-fy" it. We just said: if this becomes the proving ground for better ideas, we’re in. We’ll pull customer-centric improvements upstream. And maybe, finally, we can help the community to stop wasting energy contriburing to five semi-broken things and establish a canonical project that most people can be happy with... obviously with free binaries (which, trust me, was a difficult idea to communicate to the Synergy business team).

That’s why Synergy is involved. Not because we want control. Because we want sanity.

The work lives on in Deskflow

The good news is that the best work from those years did not go to waste. Contributions from p12tic and others, such as and TLS client certificates, have now been integrated into Deskflow.

Deskflow is the natural continuation point for anyone who worked with, or depended on, Barrier or Input Leap.

It has active contributors. It has velocity. It is not production-grade, and it is not for enterprise. But it is alive, maintained, and moving in the right direction.

If you're using Barrier or Input Leap today, you're relying on a codebase that hasn't materially diverged from work that now lives upstream in Deskflow. The differentiation will only increase over time, and the community is already migrating.

We're not asking anyone to abandon what works for them. But if you're building new integrations, debugging platform quirks, or looking to contribute... Deskflow is the better place to do it.

Deskflow: A clean break, for hackers

In contrast to Barrier, Deskflow is a new upstream community project focused on implementing bleeding-edge changes that will make their way into Synergy when ready for prime time. With an open source ethos, but without the lack of knowledge that came with Barrier development.

It’s not "productized". It’s not stable enough for enterprise. It’s fast-moving, often breaking, and unapologetically hacker-focused. But the feedback speaks for itself:

“After using Deskflow for a couple of days, I can confidently say it works so much better than Input Leap or Barrier ever did.” — user on Reddit

This isn’t to say Deskflow is ready for everyone. It isn’t. But it demonstrates what’s possible when development is guided by real engineering insight and technical clarity, not cosmetic forks with idiolistic motivations.

Conclusion

Barrier failed because it didn’t evolve. It changed surface-level traits while preserving every architectural flaw beneath. Input Leap, while a more active fork, still grapples with inherited complexity and unclear direction.

Our Synergy team perspective: We’ve learned from both criticism and forks. Our goal has never been to control the ecosystem. It’s been to build stable, cross-platform input sharing that just works.

We welcome open collaboration. But we also believe technical stewardship matters. A protocol isn’t better because it says it is. It's better when it earns it.

If you are looking for a commercially supported, quality-assured product with warranty, then Synergy is the right choice. It is maintained by the original team with decades of experience working on Synergy, tested across platforms, and backed by a support and release process designed for real-world deployment. Deskflow may be the frontier, but Synergy is the tool you can trust in production.