On Sep 25, 2012, at 7:54 PM, Tyler Romeo tylerromeo@gmail.com wrote:
Is there a reason we don't just put this in the core?
Many points have been made already in a short amount of time, which emphasizes how touchy this subject can be.
Anyway, a different view that I haven't heard as much is the following.
Being in core is not a stamp of approval. This picture never existed and if it did, it needs to go away. We're going towards a flexible modular system, which means components have dependencies and build on each other - as opposed to just "being there".
So unless other existing core functionality would need it, it doesn't make sense to include it.
Instead, extensions should prove themselves. If an extension provides functionality that other extensions need, those other extensions will simply add "Make sure X and Y is installed first" to their instructions and use it that way.
This gives a few advantages: * Fair competition. Extensions can decide that they want to use, make it also easy for developers to fork a utility and improve it (like extensions do). * Flexibility. Once it is in core, we have to support it, which is especially awkward if it isn't in use, because that means we have an untracked dependency on something we don't even use, and can't be easily replaced either because some extension might use it, somehow.
It goes at the cost of not having a standard, but I'm not sure a blanket "standard now, must use this" is what we want here, at least not until it has proven itself by being used over a long period of time by other extensions.
I mean, things don't have to be in core to be usable. Let it be an extension, let it grow. Extensions can perfectly depend on other extensions, there is no need to have it be in core, make your own decisions.
-- Krinkle