[wp-hackers] Proposing WP Flavours (various WordPress forks)

[Ken Newman]

On 12/17/2009 11:46 AM, Callum Macdonald wrote:
> Instigated in part by recent discussion on ticket 5066[1], I think the
> time has come to create a few WordPress forks. I'm imagining a set of
> patches applied against core rolled into a tgz. I can see a few initial
> options:
> * Strip out all the update checking stuff
> * Anonymize update checking
> * Security focused patches
> * Remove post revisions, etc...
>
> ...
>
> Rather than create a single fork, I propose to create wpflavours (or
> maybe wpflavors), a project to provide the means to maintain multiple
> WordPress flavours. I'm seeing an svn repo, patches (maybe using
> quilt[2]) and a mailing list.
>    
Hello,

I think that the privacy concerns are largely address by a declaration 
that WP does phone home and why that's desirable, and with a link to 
http://markjaquith.wordpress.com/2009/12/14/excluding-your-plugin-or-theme-from-update-checks/ 
for those that need to disable checks on sensitive data.

As far as forks go, I don't really think that's needed if the Canonical 
Plugins are used instead. Lots of functionality some would like added to 
core can (shortly) do so with canonical plugins.

Additionally, Functionality that some would like **removed** from the 
core could be likewise dealt with in a canonical plugin. This goes for 
non-privacy related functionality like:

   1. Code Editors for Themes and Plugins: Some people hate this and
      want it out of core, some like it tho; would make a good canonical
      plugin.
   2. The new Image Editing Functionality: Some think it adds to much
      bloat and functionality is too niche. Others absolutely love it. I
      think it should be a canonical plugin, but installed and activated
      by default.
   3. TinyMCE or LightBox: I'm using these as illustrating examples.
      Making these canonical plugins, with other versions, Colorbox or
      the text editor from google (whatever) would provide a smoother
      changing out of functionality. These wouldn't be able to be turned
      off without a substitute, which is why I included it here for
      consideration.

I bring this up because I'm not sure if its been considered how 
canonical plugins can be for moving out core functionality as well as 
bringing in existing plugins as canon.

Its also a better way to go then forking I believe.

Thanks,
Ken