There is simply no way the Hurd project as it is now can succeed, because:
1. A lot of work that went into Linux (such as hardware support) would need to be duplicated, and that would require a massive amount of time/funding which just won't be available (because Hurd isn't popular, chicken and egg issue)
2. A monolithic kernel like Linux will always be better for the common use cases due to superior performance (and currently much more features), while Hurd's advantages would perhaps be for use cases that very little people care about (for example, nowadays computers are usually personal, so running something as root is a non-issue)
3. While a microkernel might be easier to develop, or might be easier to make reliable, Linux is already extremely mature and rock-solid, completely negating that advantage
4. You can just ignore the subsystems that Linux provides and plug in your own worse performing but customized ones (e.g. alternative TCP/IP stack in an LD_PRELOAD library), sometimes even in a very clean and standard way (e.g. filesystems using FUSE, block devices with nbd, network with tun/tap)
5. You can use virtualization, containers and several other mechanisms which provide similar "system in a process" features while continuing to use an existing popular and full-featured OS
Overall, the only way the Hurd could turn into something useful is to change it to use (unmodified) Linux instead of Mach/L4/whatever as a "supporting microkernel" and turn the Hurd into a set of Linux system daemons providing ad-hoc IPC interfaces (like the existing dbus, systemd, PolicyKit, ConsoleKit, etc.) and into FUSE filesystems, assuming that there actually are any useful parts that can be salvaged that way.
Should Linux have any shortcomings (like maybe too slow IPC/message passing, or inability to easily implement some things in userspace), those could be addressed in a generic way and then merged upstream as overall kernel improvements (like FUSE).