A few days ago, chemical pointed out to me (again) that the context-sensitive commands in hnshell sounded like a good idea at first, but is completely unusable in reality. The fact that you have to type four commands in order to change a server is simply stupid. For those readers who actually haven't used hnshell and/or haven't figured out how this works, here's what you'd need to do to change a server:

$ cd modules
$ cd ed2k
$ cd serverlist
$ connect Razorback

Similar command sequence is required to view current server connection status. Yet initially, everyone was so excited about the innovative and cool idea of context-sensitive commands. Which brings up the point - many ideas sound cool and useful as ideas, but fail miserably in real world and/or have very limited usability, so affect only a very small amount of userbase. Unfortunately, Hydranode is full of such ideas. Basically Hydranode is a huge collection of such ideas, all stuffed together into a single application.

When big corporations start considering a feature or idea for a software, they spend a lot of money on research before starting any development, simply because it's a lot cheaper to find out an idea isn't worth the time/effort/money during research rather than spending millions on a feature that only 0.1% of userbase actually uses. Yet in open source world, this is not done, since the general direction of thinking is that software should include features for everybody. This is actually inherent from the fundamenatl idea of open source - everyone can submit patches - and developers rarely say no, resulting in feature/idea bloat.

Hydranode was started based on a lot of ideas - actually all of Hydranode's ideas were developed / designed during first 2-3 months into the project (summer 2004), since then no ideological changes have made, and very little, if any, new concepts have been introduced. Looking back, Hydranode was actually started because at the time, xMule (where I was maintainer at the time) was an awful codebase, lacked core/gui separation which was, again at the time, the "holy grail", and only supported one network. ShareDaemon project was created to address those concerns, and after the failure of that, Hydranode, based on the same ideas, and quite a lot of new ideas. Yet all those ideas are niche features which add very little value to the final software, while each one of them exponentially increases the development time.

Taking one by one - cooperative multi-network downloads is perhaps the most fundamental idea of Hydranode. Or, in a wider scale, multi-network downloads in general. Yet how many successful multinetwork applications do you know? Both mldonkey and shareaza have shown extremely bad network behaviour on all networks they support. It isn't because they such at coding or lack the skills - ShareAza code, for example, is very high quality. It's because the fundamental idea of multi-network client is flawed at it's roots. When you develop a single-network client, you spend all your effort to support that net, and it usually takes 4-6 months to become a considerably-good client for ONE network, about a year to win the market. In multi-network environment (leaving aside the added complexity of multi-network handling itself), the effort is automatically split between multiple tasks, leading inherently worse performance on all supported networks. It's not something the developers intend, but it's inevitable.

To add to that, the idea of true cooperative multinetwork downloads is also a very weak one. With the addition of BT module recently, Hydranode is capable (under certain conditions) of downloading files cooperatively from ed2k and BT. Yet the amount of torrents that actually have hashes for both networks, or even if there was a DHT backend which supplied those hashes, the actual use for such a feature is very limited - all networks are self-contained, and the fact that you can leech off two networks can actually be harmful for both networks being involved, while giving very little speed / reliability increase. Yet another useless feature that sounded good as idea but is useless in practice.

Another idea - core/gui separation. It has very little use for local usage (shutting down GUI and leaving core running - maybe some 10-15 ppl might find some use for it). And for remote usage, it only makes sense for people who actually have TWO computers at home, possibly one running some unix variant. Imagine how large amount of users actually have that? Considering that 5% of the userbase actually use linux, 0.5% use both linux and windows in a multi-computer environment... and the remaining 99.5% of users suffer from the added performance penalty of inter-process communication. It is also a major hit on overall development time (the cgcomm code isn't a trivial task), the added bugs (more code == more bugs), and as practice has shown, it means that it takes longer for the project to attract user/tester base due to lack of user interfaces in early/middle stages of the project. Such large penalties for a feature that a VERY small group needs.

So based on that, isn't Hydranode just a big bucket of ideas that have little or no value at all?

Madcat.