On Tue, 7 Sep 2004, Alan Horkan wrote:
We should be taking advantage of that work and avoiding Gimp Gradients (the .ggr file format) and encouraging them to use SVG instead and standard file formats in general (gradients are inherently vectors anyway).
This is a good point that Gimp should be encouraged to support the SVG gradient format, and certainly one of Inkscape's core goals is to seek improved compliance with SVG.
However, as a general policy I don't know if we really want to use feature disablement as a mechanism for achieving those goals; it seems a tad manipulative. Instead of "using the stick", I think we will get better results and better inter-project relations via "using the carrot" type approaches.
Adding support to Inkscape for a Gimp file format seems to me to be a good example of a "using the carrot" approach. This creates a valuable feature that helps Gimp users make better use of Inkscape. Rather than disincentivizing Gimp developers from needing to support SVG gradients, I think it serves to increase the awareness of interoperability between the projects, and opens the question, "Well, if Inkscape supports X from Gimp, doesn't it make sense for Gimp to support the converse from Inkscape too?"
In general, I would think that we'd want to enable or disable a feature specifically on that feature's qualities. For example, if it requires an unusual dependency or would add 'bloat' to Inkscape, it makes sense to either not ship it with the core, or provide it as a non-default option. In the case of the Gimp plugin it may make sense to ship it separately for the purpose of serving as a proof of concept for the extension system, for example. However, if there are no technical or legal considerations to its use, and if it's a worthwhile feature that will benefit developers or users a lot, then we should include it. One of the founding principles was to keep development open and to be as inclusive as we can of the features that can be added to the codebase.
Bryce