In reply to George Stephanis.

I just followed your stats, didn't bother to check what exactly were you counting so me bad here, but whatever you count the end result is similar especially when you remember that part of the core code is themes and libraries that are included as a whole when only part of them are used (I guess you can argue that this is how you should include 3rd party libraries, but in the case of tinymce IIRC it includes two skins that I never ever seen or heard used) and some libraries just for backward compatibility.

Wordpress has a design philosophy of "decisions not options" which means that the end result of core development is to produce a product which has very few execution paths which are not going to be used in the life time of a site.Links went out although the menu feature is not a 1:1 replacement for them and so did publish by email. I am sure there are some more areas of core to trim (pressThis....) but even an exporter is not part of the core now.

This means that whatever liability in terms of security and bad software design the wordpress core has it is something that I have to agree to live with it or not use wordpress at all. There is no option of forking wordpress to my own needs as there is no obvious "fat" left to cut out of it.

And still, I am upgrading wordpress when a new version comes out. first I wait for the .1 version and even after the qa is finished I will still run some real traffic over it to test even more execution path then the qa process tested before going full production with it. And this process is absolutely needed because new versions of core are know to break things because of some subtle changes in the way wordpress api works or 3rd party libraries changes.

Now imagine this process needs to be followed for every plugin upgrade......

For small plugins the answer is easy, I just fork them when needed and don't really care to upgrade. But jetpack is just too big for that. Its development process is not transparent, its code is not audited by the same amount of people as core and it is not tested in as many different server environments. In the last year you have released 12 versions and from the change log it doesn't seem like it was only a must fix security problems which means that you too easily open to feature creep and your QA process is not good enough.

And about this "code not executed when disabled", isn't it basic security recommendation in the wordpress world to delete unused themes and plugins? do you remember timthumb?

And no, how photon works is not important as it is illegal to use it with a forked jetpack under its TOS. So in addition to the code liability the is also the legal liability of using all those service with a forked jetpack. which makes forking it as I do to other plugins a dangerous thing to do without a continuous legal advice.

As for the security..... you are bypassing all security practices of core so there is no plugin that can enhance the security of your communication, and since you do not follow any standard security protocol I am going to doubt your security procedure is actually bullet prof. In any case it is enough for someone to get control of wordpress.com by hacking or legal means to control all sites using jetpack without letting their admins to install any safeguards against it. And this is really the most unacceptable part of jetpack, and a part least advertised in the jetpack feature list.
Everybody is aware that their google and FB accounts might be inspected by authorities but how many are aware that their silkroad clone can be remotely inspected just because they have installed jetpack to use the contact form feature?