Zncflaws
Why we must replace ZNC with psyBNC
ZNC requires users set up dozens of connections
ZNC requires your IRC client make one connection per network. If a user wants to connect to 10 networks at once (freenode, ircnow, dal, efnet, etc), it requires him to set up 10 independent connections on his IRC client. This is almost impossible with mobile apps and very confusing for GUI apps. Practical experience has shown that <30% of bouncer users know how to do this. If you rely on ZNC, you will lose >70% of potential users. ZNC developers have declared they have zero interest in fixing this design flaw.
ZNC has a confusing way of logging in
If your username is john, your password is secret123, and you want to connect to freenode, your password field needs to be john/freenode:secret123. If you want to connect to dal, your password field needs to be john/dal:secret123. This is an unintuitive way of changing networks. Users don't understand this without 1-2 hours of troubleshooting.
ZNC is not designed for casual users
It requires reading far too much documentation in order to use. For example, typing /msg *status help shows a wall of text that only a sysadmin could understand. Jargon like AddTrustedServerFingerprint, ClearAllChannelBuffers, and SetUserBindHost are exposed to users -- words that only a sysadmin could understand after reading through several pages of wikis. As sysadmins, we should configure all this for the end-user so the end-user does not have to read a single page of documentation.
ZNC relies on a web panel
There are two problems. First, I suspect this web panel cannot be easily customized without recompiling. Secondly, it does not follow the UNIX philosophy of Do One Thing and Do It Well. There is no need to bundle a web server with a bouncer. These should be two separate programs because they deal with two separate protocols/objectives. There is no real need for a webpanel at all. There's nothing in the webpanel that could not be configured and managed by sysadmins on behalf of users.
ZNC is written in C++, an inelegant language.
ZNC throttles users so it can take hours to connect
The throttling is done poorly -- each connection is attempted and throttled serially, even if the networks being connected to are different. These connections should be done in parallel rather than serially. For example, if you have 30 independent networks to connect to and a 30 second throttling delay, it would take 15 minutes with ZNC, but it should only take 5 seconds with a proper bouncer that connects to all 30 networks simultaneously (no need to throttle because they are all unique). On a ZNC server with 1000 users, it can take hours (maybe days) just to connect.
ZNC will disconnect users and throttle if SSL certs are not properly signed
If a server doesn't have a properly signed SSL cert, ZNC will disconnect until the user adds the SSL fingerprint manually. This confuses >90% of users. They always blame our bouncer for not working properly. To make matters worse, ZNC then insists upon reconnecting every minute or so and failing in the same manner. And because ZNC does connection throttling, this slows everyone from being able to connect. You as a sysadmin are forced to manually disconnect networks that have SSL certs that aren't properly signed, or else in a few weeks, your ZNC becomes so slow (due to all the throttling) that it takes >10 mins to connect.
ZNC throttles everyone if someone is glined
When someone is GLINEd, ZNC tries to reconnect every minute, causing everyone to suffer from connection throttling, even if they are not GLINEd.
Upon disconnect, ZNC loses all messages
ZNC loses all its messages if you are ddosed while away, or even if there is a simple brief 10 minute hiccup in networking. When this happens, every single message is lost.
ZNC adopts a protocol that introduces new bugs without new features
ZNC chose to adopt IRCv3, an unnecessary protocol which adds nothing of value to users but introduces a lot of bugs. We have documented that older versions of mIRC (from around v7.33 to 7.41) are unable to connect because either mIRC or ZNC improperly implement IRCv3 capability negotiation. This bug has also been observed with some other Mac and Android IRC clients. What is worse is that nothing in the system logs or user clients ever show this error; it just appears to be nonresponsive after IRCv3 capability negotiation. We are able to reproduce this bug.
In another documented bug with ZNC, mode changes don't show up properly on InspIRCd v3.
ZNC can't prefer IPv6 by default
If you try to support both IPv4 and IPv6 simultaneously, ZNC will not prefer IPv6 when available, and there is no way to fix this currently short of a custom patch. If you want to prefer IPv6, you are forced to drop support for IPv4 (you are therefore unable to connect to IPv4-only networks). If you choose to support both IPv4 and IPv6, znc usually chooses IPv4 by default, rather than using IPv6 by default. This is a design flaw. The default should be IPv6, then fallback to IPv4.
ZNC module relies on commands not supported on all IRCds
The ZNC NickServ module appears to use the /nickserv alias which is not supported on all IRCds (not supported by ngircd). The proper nickserv module should instead adapt to each IRC network so that users do not have to memorize the idiosyncrasies of every single network's services. For example, for ngircd, the proper command is /squery nickserv identify <password>; for DALnet, the proper command is /msg nickserv@services.dal.net identify <password>. This really does not need to be an optional module; it needs to be integrated into the bouncer.
ZNC does not offer any easy way to download chat logs
It has a chat log module which stores the chat logs on the server hard disk -- but how is a user supposed to fetch these logs? Unless you give every single user on your bouncer ssh access, you are forced to manually email them.
ZNC has no way to register instantly upon connection
Requesting a ZNC account using a web registration form or a bouncer bot is bad design. Users should be able to register an account instantly upon first connection.
ZNC has poor security
ZNC bundles the shell module by default, a module which makes it easy to exploit a 0day to get shell access to the entire server.
ZNC's Partyline module is buggy
When users are connected to multiple networks, messages often repeat 2x or more, and sometimes it causes the users to join strange channels without requesting it. This otherwise useful module has been dropped starting v1.8, so we will need to switch to psyBNC to keep it.
ZNC's blockuser module may be buggy
I have not verified this with certainty, but I suspect that if you send a reconnect message to the *controlpanel, it may connect sometimes even if a user is blocked.
ZNC can't be made secure without chroot
With psybnc, we can use pledge and unveil.
ZNC treated IRCNow as a hate group
In the ZNC Providers page, IRCNow was falsely accused of being involved with hate activities.
This accusation was made without a fair trial or ability to appeal. Since the development team is not friendly to our goals, IRCNow should not rely on their software.
Confusing mobile support
A commonly requested feature is to be able to use ZNC for both mobile phone client and PC IRC client. Here's the ZNC wiki explaining how you have multiple clients. This setup is too complex and confusing for normal people to follow.
No open source push notifications
ZNC modules often fall into the category of 1) not useful or 2) proprietary software. For example, the ZNC Push Notifications module is proprietary software. There is no open source push notifications for ZNC, but this feature is essential for a proper mobile IRC client.
Development team has different goals
ZNC developers most likely have no interest in fixing any of the above design flaws. You are better off forking the psyBNC code yourself and fixing what needs to be done.
psyBNC may not be complete, but at least we can fork it and design it correctly.