On Thu, Oct 29, 2009 at 9:25 AM, Christopher Howard <choward@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx >> 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 Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
