Re: The naming question (Postgres vs PostgreSQL) - Mailing list pgsql-advocacy

Hi,

First, this is my last email on this topic.  I don't actually care
that much if people want to change the name.  I'm just trying to
point out that it seems to me to be more work than people think, that
it might actually do harm by introducing another variable to the
message right when marketing efforts appear to be yielding some
fruit, and that it will cost us not only time, but money.  That said,

On Tue, Aug 28, 2007 at 05:29:03PM -0400, Bruce Momjian wrote:

> OK, let's look at the items required for a name change.  Right now our
> FAQ says "Postgres" is an acceptable name for "PostgreSQL", so the idea
> of allowing Postgres as an alternative is already done.

Right.  So why are we wasting time on all the other stuff?

>     1)  URLs, can use redirection

Yes, but the "branding" people tell me that what you really want to
do is get people to stop using the old form eventually.  To do that,
you have to set a date for the end of redirection, and you have to
have a plan to meet that date without losing people.

>     3)  email list names, keep pgsql-*

Oh, that'll be intuitive to a new user.  "Hmm, I have this product
called 'postgres', so _of course_ the list name is 'pgsql-general'."
If the point of this change is to reduce confusion, then the "SQL"
has to be removed _everywhere_ within one release.  Otherwise, people
who know nothing about us will be asking, for years, "Why did you
fork from the PostgreSQL project?"

>     4)  web site content, search/replace

You can't do "search/replace" on images. On the web page, for
example, we have hdr_left.png right at the top.  Apparently, the
person who designed some of these things for us is no longer around,
and we don't have the font that was used.

And maybe it won't look as good when rendered as "Postgres".  We have
to consider the possibility that the renaming will require
redesigning all sorts of graphical elements; and that only a minority
of the community has any graphic design skills.

>     5)  tarball names

And all the scripts that generate these things, as well as all sorts
of scripts that random people (i.e. established users) all over the
world might have.  Some of those people won't be watching this list,
and we don't know how they'll find out about the name change.
Changing these supports scripts will then be one more thing they need
to do before upgrading, and so that's yet another drag on getting
people to stop using old releases and get the benefits of the new
software.

I want to point out that the various Mozilla name changes were not
without pain for their users, and they _have_ a giant marketing
machine that takes out adverts in newspapers.  We have a committed
group, but many of us are (let's be honest) basically geeks with at
best faint clues of what works for marketing to CTOs and the like.

>     6)  source code copyright notice
>     7)  postgresql.conf, rename

See above about scripts.  Do you _really_ want to make every package
maintainer adjust any scripts they have for copyright notice checking
or postgresql.conf adjustment?  Do you need to form some new
unincorporated "Postgres Global Development Group" to work on the
newly-named software, or use the old expansion of PGDG?  If the
latter, will it be confusing to users (or anxiety-producing to
potential users, who are already skittish about this strange thing
where a bunch of geeks on the Internet write and give away the
software the potential user is considering)?

Will the apparent regular name changes cause people to suppose that
the development community breaks up and forks a lot?  Will the name
changes cause software distributors to distribute both the last
version of PostgreSQL and the new Postgres, because the latter is
obviously a fork of the former?  Will we be inundated with questions
like, "Is the Postgres fork new code?  Does it use
threads/mmap/Java/Ruby/other SuperKeenFeature?"

I don't know the answers to these things; but it seems to me they
_need_ answers before changes happen.  When you change the name of a
piece of software, you have no problem communicating it to the users
you're in regular contact with.  But the users that you're _not_ in
regular contact with -- never mind the users you don't have yet --
may end up confused or needlessly anxious, because you have taken
something familiar and changed it in a way that is very visible.  For
software that, to a lot of people, "Just works, so I don't think
about it," you're _making_ them think about it.  It might be worth
that cost, but we need to figure out what the effects might be before
we cause them.

> I think an interesting approach would be to change the software name to
> Postgres but keep the community/project name as PostgreSQL Global
> Development Group.  That would allow us to keep using both and minimize
> changes.  It would allow the places we don't change to remain accurate.

It will also cause utter confusion among people who already think
this whole free software thing is a little funny: "These clowns can't
even keep their name straight.  What's wrong with them?"  If you
change, you can't do it part way.  The _status quo_, where everybody
just says, "Postgres is a short form," is understandable.  It's way
harder to say, "Oh, right, well, that part of the web site didn't get
updated after the name change."  I can tell you that many of the
pointier-haired types I know would dismiss the whole project on the
basis of that sloppiness alone.  And that'd be a possible user we lose.

A

--
Andrew Sullivan  | ajs@crankycanuck.ca
However important originality may be in some fields, restraint and
adherence to procedure emerge as the more significant virtues in a
great many others.   --Alain de Botton