RE: How to Prevent Hostile Takeovers for a Naive Steem Community

My first reaction to this is Kudos. It's about time this was pointed out. My second reaction is not to consider your specific proposals, but to consider the weaknesses they are intended to address, and their etymology. Why have we been so naive as to engender exposure of our soft white underbelly to 'foreign' capital?

In part, this is the legacy financial model. Rather than decentralization, industrial capitalism is based on centralization. Stinc being a stock corporation has allowed @ned to undertake this transaction at his sole option, because of his centralized stake. Not his stake in Steem, but his stake in the corporation. As the majority stockholder, he had centralized governance in his person completely, and this is a feature of institutions that subjects those seeking more power over them to the 'dog eat dog' office politics that favors the least socially functional in the scrabble for power. It has been often noted that psychopaths tend to gain power, because they are more willing to undertake socially unacceptable means of gaining it.

This is not in reference to @ned whatsoever, whom I am sure is a nice person. Due to the specific eventuation of Steemit, his accession to that majority stake was accomplished much differently than the model I just outlined. However, nice @ned has parted with that stock, and now it's out in the wild, where raving psychopaths indeed roam seeking power. 'Like lions, seeking whom they may devour', to get Biblical.

So, legacy business models necessitated by capital accumulations enabling institutional operations intruded on the decentralized mechanism Steem is intended to be. Additionally, the ninjamine enormously skewed distribution, and this has been a constant debility for decentralized development. From rewards mechanisms to powerdown duration, the stake wielded by whales has been the primary interest of development, rather than the growth and health of the social network and decentralization of the blockchain, particularly regarding governance.

Understanding these causes of the weakness and naivete of Steem and it's community may enable us to improve governance models such that decentralized blockchain social media platforms may be designed to inherently resist hostile 'foreign' capital and takeovers, as well as distribution imbalances. Certainly there are more, many more, sources of naivete and weakness, and it will be necessary to understand them to the extent possible as well.

However, this doesn't help us now, as Steem is what it is, regardless of why it's that way, and we need immediately actionable means of securing it from hostile takeover. I reckon @starkerz ideas are pretty functional, and obvious ways Steem needs to instantly adapt to this situation. Tron, as you point out, has acquired Steemit, it's development business, infrastructure, and team, as well as an enormous quantity of Steem.

Presently that quantity of Steem is sufficient to enable Tron to do exactly what @ned did to Steemit to Steem itself, and effect governance at it's sole option. While Tron may deeply desire to remain the God King of Steem governance, Steem will be more valuable in the long run if God Kings aren't potential to it, and even Tron will benefit from this immprovement in the long run.

@bryan-imhoff correctly points out that changing the way stake votes for witnesses directly ends that threat to Steem governance. I suggest we immediately HF to solely implement the suggested change so that 1 Steem equals 1 witness vote. This will not eliminate Tron's influence on Steem due to it's stake, but will preclude it being competent to effect governance of the blockchain at it's sole option.

Further, I particularly like the third idea @starkerz discusses of decentralizing development from a centralized corporation to individuals or companies paid through the SPS. This will prevent that holdover centralized legacy model of institutional control from again threatening the development of Steem, whether Tron puts Steemit devs to other work or not.

The first proposal @starkerz makes is a done deal, facile, and well achieved I believe. The idea to keep that fork current, and to implement SOP as to when to trigger a defensive HF is a good idea that we can explore and undertake going forward.

I reckon having a backup token ready to fire up at will is a good idea too.

Thanks!