Re: terminology



Ilan Volow wrote:
> 100% chance. We have their source code, remember? Free
> software (I'm sounding like a broken Richard Stallman
> record, I know) means that if one person (or a very
> large corporation, foundation, league, etc) are doing
> things with the UI that you know are tremendously
> user-hostile and will really ruin the total user
> experience, you have the opportunity to make changes
> to their code and publish your own version. You can
> give your users something that the other guys refused
> to give them. Take *that* Jim Allchin. ;)

Umm, forking software for just very minor issues like this is not a
really nice thing to do, although possible. I would argue that it isn't
even wise either.

It has lots of other complications. Will the new project with the
changed term be equally well maintained as the original? Will it have
the new features of the original project? Will you manage to keep up
with those? Will you be able to introduce other new features in your
version to attract new users? Will you be able to keep up with bugfixing
of your existing code? Will you be able to attract other developers to
help you? And so on. Basically, this would make you a maintainer of lots
of applications, and maintaining is a tough job. Maybe maintaining X
forked projects just because of a slightly changed terminology is not
something you'd like to do if you're just an UI guy.

The proper use of free software is not to duplicate other people's code
or coding efforts. The real power is to be able to improve upon other
people's work and share your efforts and freedom, and build on from
there. That often requires collaboration with the applications author or
maintainers. Just browse around on Freshmeat, and you'll realize how
many people make this mistake - starting your own project is not the
solution to everything. It's hardly even the solution to most things.
Unmaintained software is useless, and ten or twenty different projects
all doing the very same thing with very minor differences in code and
goals is often not useful either.

Use the source to make PATCHES with your wanted change and send them in
to the maintainer(s). That's a good way of using the source. If the
maintainer says "I don't like what you want to do and I will never allow
it in my project, and if you come here again suggesting that it should
be done I will personally hunt you down and harass you and your family
for eternity", only THEN maybe you should consider other measures like
forking the project (but only if you believe that could be done and
properly maintained afterwards). Not a step sooner.

That's what we should do. We should file bug reports for the various
projects in which we find bad terminology (http://bugzilla.gnome.org
will do for most of the gnome projects) telling what should be changed
and why, and optionally add patches to the bug reports that fixes the
mentioned problems.


Christian




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]