Re: The naming question (Postgres vs PostgreSQL)
От | Andrew Sullivan |
---|---|
Тема | Re: The naming question (Postgres vs PostgreSQL) |
Дата | |
Msg-id | 20070829154058.GM4183@phlogiston.dyndns.org обсуждение исходный текст |
Ответ на | Re: The naming question (Postgres vs PostgreSQL) (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: The naming question (Postgres vs PostgreSQL)
("Gavin M. Roy" <gmr@myyearbook.com>)
Re: The naming question (Postgres vs PostgreSQL) (Josh Berkus <josh@agliodbs.com>) |
Список | 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
В списке pgsql-advocacy по дате отправления: