On Thu, Oct 29, 2009 at 9:25 AM, Christopher Howard <chow...@indicium.us> wrote:
> John B wrote:
>> Well, if it's out of the question, then I guess I'll just shut up
>> before this becomes a big argument.
>> _______________________________________________
>> Gimp-developer mailing list
>> Gimp-developer@lists.XCF.Berkeley.EDU
>> https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
> It seems to be "out of the question" as far as convincing the developers
> here to ever do that. Under the terms of the GPL3, however, there is
> nothing to stop you from forking the code and doing that yourself.
> Probably the best way, I would imagine, would be to keep nearly all the
> code the same, but to add a configure options (like "--better-name")
> that causes the logo and title bar name to be replaced. But if you were
> to go to all the trouble, you would want to come up with a really classy
> name and well-designed logo or else no one would care.
> I'm sure that has been mentioned in the archives as well, but I thought
> I'd mention it again in case you actually had the time and interest to
> do it. Personally, I don't like the name GIMP either, as it's not a very
> selling name. I know that annoys many of the (dedicated, hardworking)
> developers, but we all have the right to our own opinion.

It doesn't really matter that much to the developers *what* it is
called, as far as I know.
The point is really the branding... changing name will definitively
LOSE a lot of users, no matter what the current name is or the
intended name is.
There may be solutions to this problem (though commercially,
rebranding seems to involve a lot of expensive advertising). So far,
no-one has proposed one (or demonstrated that the current name is
problematic in an actual provable way -- just assertions that it is
offensive or not offensive in so-or-so region.).

All the above comprise a significant factor in why forks are regarded,
at best, as a necessary evil. All forks dilute branding, which
introduces user confusion and repels potential users.

So I do agree with one thing you said -- If you were to fork the
project you would need to do so really well. This would probably
involve forking the gimp-docs and gimp-gap similarly (and maybe also
FX-Foundry) in order to cover the 'gimp' references in these most
commonly installed accessories. It would also be important to make it
very clear that it is compatible with GIMP plug-ins, and therefore to
search GIMP's global plug-in/resource directories for resources as
well as the fork's plugin/resource directories (identifying and
ignoring duplicate resources). It would require the mascot to be
changed (and therefore also some of the icon set, as they include
Wilber), and also some (all?) of the gimp-docs screenshots, as well as
some of the example images in gimp-docs which use Wilber. It would
require a strategy for dealing with existing .gimp-2.7/ directories.

That's my understanding at a glance. Actually doing it well would be
more involved than the above, I expect. (for example, we use the
phrase 'happy GIMPing!' and similar verb-ing of the GIMP name.. so it
would help to have the replacement name be easily verb-able too)
Gimp-developer mailing list

Reply via email to