Thanks for sharing your thoughts, and I appreciate that this kind of change is scary. I assure you that we are fully confident in this release and there are serious downsides to delaying that you do not mention. Steemit and exchanges are prepared for this date and we cannot promise the same will be true of any other date. That being said, of course, if the witnesses decide to delay the fork, we will do our utmost to ensure that date is met, however, it will undoubtedly lead to delays with respect to other product releases like SMTs.

If we believed there were serious risks with hardforking, we would recommend a delay. The halting incident is now well understood and the relevant code has been thoroughly audited. That risk has been eliminated.

The last minute changes, specifically those in 20.2 were added to ensure a smooth transition to the new RC system. These are not significant changes. What we realized thanks to @timcliff's testing is that the new RC system, which appears to be functioning as intended, would lead to unpleasant UX because the bandwidth algorithm is under-pricing many ops. We added some code that we believe will ensure that user experience remains consistent as the RC system equilibrates. We could have not added that code and the system would have worked perfectly, aside from a temporary hit to user experience. We just wanted to make sure Steem maintained a good UX. That being said, compared to previous hardforks, these are not last minute changes. If you go back and look at previous hardforks you will see more updates closer to the release date. But none of this is relevant. What is relevant is that the best Steem blockchain developers are confident that the 25th is the best day for the fork. To delay would be to disregard their view that the risks associated with delaying are greater than the risks of hardforking (which they believe are minimal).

I think the real mistake here is thinking that the lead up to any hardfork is going to be stress-free. We are all working our hardest to make sure that the hardfork goes as smoothly as possible, and believe it or not, that can be a stressful experience! That means more people start testing stuff and more tweaks need to be made to respond to that testing. The question is not whether changes are made, but what types of changes? What parts of the code are they altering? For example, 20.2 only modifies the initial state of the resource pools. It doesn't change anything about how the resource pools functions. That is the important distinction: are we rushing because we believe we can make this hardfork work and make Steem better as planned or are we rushing because something is broken and we don't know how to fix it? While the halting incident and Dlive might be contributing to FUD, they have little to do with HF20. Our exhaustive audit of the portions of the code around the halting incident is complete. The halting incident was an example of the blockchain's safeguards functioning properly. The reason why witnesses run the testnet is to expose bugs. Bugs were exposed. It is not reasonable to expect that leading up to major changes all tests will be passed and all versions will be perfectly complete. This is, for example, why some code is alterable via softfork.

Dlive leaving Steem is entirely irrelevant. They were never intending to stay here and this is an open source protocol. Apps are free to come and go as they please. I understand this might seem like a big deal to Dlive users, and may contribute to FUD but that is something they should take up with the people at Dlive and should not be part of the debate about whether to hardfork or not.

I would just like to close by reiterating that I promise we would never recommend this if we didn't think it was a safe course of action and the right course. Of course it's not the end of the world if we delay, but it is not as "cost-less" as you make it seem. The main cost is that it will seriously delay our other efforts. We really want to shift as many resources to SMT development ASAP, and a delay would seriously interfere with that and, again, for no good reason as far as we're concerned.