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

[William Canino]

Considering its thousands of action and filter hooks -- and more and
more made in each release, in my opinion, WordPress is too
customizable and open-ended to need particular forks.... that is,
unless a very good programmer (or a group of them) comes up with a
direction for WordPress that the lead devs (Boren, Jacquith,
Mullenweg, Ozz and Westwood) feel strongly against.

Realistically, the lead devs cannot allow/approve every kind of patch
that will be suggested that disables features or takes WordPress in
every sort of direction.  While a plugin developer might say, "Hello,
here is a one-line diff that will let WordPress handle Foobar content,
I think people will find it useful," if the trac discussion says
wont-fix, it's a wont-fix.  I can see how the wont-fix feels to the
plugin developer; the word "fork" will come to her mind.

I haven't yet worked with WP Core closely to see how open-minded or
politically-heated trac discussions get. To Foobar plugin developers:
go right ahead anyway, strut your stuff, tell your plugin users to add
that line as an installation step!! Don't ever let anybody tell you
your idea isn't worth shit.

Thank you for letting me speak.

W.

2009/12/17 Ken Newman <Ken at adcstudio.com>:
> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>