This should be taken with a very large grain of salt. Firstly, its author, Mircea Popescu, has a long history of not being the most trustworthy character, and often deliberately incites flamewars. I say this not to discredit the arguments in the post by discrediting their author (that would be fallacious), but to warn readers against taking his words at face value.

Now, on to the points in the post.

>As best as anyone can currently discern, Bitcoin does not have a core group of developers.

There is, in fact, a group of developers which contribute the bulk of the new code to the Bitcoin-Qt client. This includes essential security updates and new features. They also have a certain degree of leadership in the Bitcoin community, and their word was enough to get a majority of miners to switch to one client version during the hardfork (more on that later).

> The “Bitcoin Foundation” / “Core Devs” group of scammers have quite publicly, and repeatedly, promoted and vouched for Butterfly Labs, aka BFL

I am not a fan of BFL. Whether they are malicious or incompetent does not matter with respect to the financial damage they have done. More importantly, they did not provide adequate compensation for their unrealized promises after the damage was done. However, I will need to see evidence of the Bitcoin Foundation endorsing BFL before I believe it. Additionally, while one or more developers may have endorsed BFL, this does not mean all developers which contribute frequently are in a cabal together.

> The “Bitcoin Foundation” / “Core Devs” group of scammers have quite publicly, and repeatedly, promoted and vouched for MtGox

Please see my above response and substitute "MtGox" for "BFL".

> Systematically attempted to block, slow and hinder protocol specification and development

Such an accusation requires evidence.

> Deliberately and quite maliciously created a blockchain hardfork in March 2013

Without evidence, we should assume it was accidental, not deliberate. In fact, I would assert that the evidence we have strongly implies that the fork was accidental. The hardfork only occurred because of a specific block that was "too big" (simplification). Additionally, the bug which caused it existed for a while before the fork occurred. Then, many of the core devs worked with miners to resolve the fork in such a way that every client managed to reunite on one chain.

> which allowed our enemies - whoever they may be - to effectually stress-test the entire project

This is a nonsensical statement. The fork revealed no new "weakness".

> Deliberately and quite maliciously tried to meld the BleedingHeart openssl vulnerability into the Bitcoin code.

Again, we should assume they did not know of the vulnerability. If they did, then this point should be expanded upon and not blended with the rest of this post.

The post ends with vaguely threatening text which I will not quote here.