On Sun, Aug 21, 2011 at 5:21 AM, Terry Ellison <[email protected]> wrote:
On 20/08/11 21:00, Rob Weir wrote:
On Sat, Aug 20, 2011 at 3:47 PM, Dennis E. Hamilton
1. One has to do with [email protected] where this is a personal
forwarding set up for some user (or entity) and it forwards to another
e-mail address. If these are preserved, forwarding them to some
other email
address to then be forwarded to the original entity does not make a
lot of
sense. The issue here is that the entity is known by that email
address and
has connections that access that entity by that email address.
It is a good idea to preserve that service so that the entities that
have use of the individual ones can somehow manage their forwarding. I
would not want to figure out how to retire it until later, and with
considerable warning. Having an individual's e-mail address
disappear is
not a pleasant experience.
... How does this help us develop and publish open source software? ...
There seems little point in developing any FLOSS package which
doesn't meet
the needs of its user population, as we will end up with an unused
product.
Sure. But we do see other open source end user productivity
applications produced without the use a wide-open email forwarding
service, e.g., KOffice, AbiWord, LibreOffice. I'd even included
end-user oriented Linux distros and other apps like Firefox,
Thunderbird, etc. So the email forwarder is not essential to
success.
In some cases, email addresses were made selectively available. For
example, KDE makes them available to only core contributors, as
explained here:
"I am sorry but in the past, people misused their KDE email address to
tell
nonsence about KDE and of course people thought that it was the
official KDE
position, as they had a @kde.org address. Unfortunately, it has not only
happened once. That is why there is now the restrictive policy about KDE
email addresses."
http://lists.kde.org/?l=kde-www&m=106902943009944&w=2
Apache has a similar policy, and makes the email address available
only to project committers.
I repeat that OpenOffice.org targets the general PC-owning
population as
its user-base. This is very different to Apache Server, Traffic Server,
Subversion and the other Apache projects that typically have a niche IT
proficient and often IT professional user population. Clearly, the
success
of any FLOSS package depends on the support of a committed core of able
developers. However, the success of OOo also depends on a wide
community of
contributors, documentation and tutorial developers, community
supporter and
even just power-users who can evangelise the product.
Every person and every project wants to think that it is special, that
it is different from all others. OK. That's fine. But let's not
overstate the differences.
Remember, Subversion has an awesome book [1], Apache has great
tutorials [2], etc. They manage, somehow, even lacking thousands of
evangelists with subversion.org email addresses.
[1] http://svnbook.red-bean.com/
[2] http://httpd.apache.org/docs/current/
OOo is not special because it has documentation and tutorials.
We have historically encouraged this community to use their oo.o
mailboxes
to foster a sense of identity. I know that I used to use my
[email protected] address a lot: answering end-user emails and as my
email address for a range of forums, wikis and similar services. I
was and
As I understand it, these addresses were given out freely to those who
registered for Bugzilla. But I also see hundreds of Viagra spam notes
in OOo Bugzilla. Do you see even the slightest risk here? The self
identity of the volunteers is important. But so is the identity of
the project, including the integrity of the trademark. It should
never be ambiguous whether someone is speaking on behalf of the
project. "Hats" at Apache are very important. We should not be
giving out thousands of hats that suggest someone is an official
representative of the project.
If we're looking for ways to indicate support and promotion of the
project, this can be done in many ways, from banners people can put on
their websites and blogs, to email signature blocks.
(IMHO, we also should all start being proud about being an Apache
project and having an Apache email address. )
am proud to be associated with this project. However, because I realise
that the address might go away, I had to trawl through my emails to
work out
which services I had subscribed to using [email protected] and rehook them to
another mailbox: a real pain -- but less painful than suddenly
finding out
that I had become disconnected from them. So my answer is that
alienating
our extended community of supporters would not be something that we
should
do lightly. OOo depends on their support.
If we just pulled the plug, that would certainly be alienating. I
agree with you there. But I still don't see these forwarding
addresses as being beneficial to the project. Aside from avoiding
offending the volunteers, you haven't shown why they are a benefit to
the project.
If Sun had sent a fruitcake to every volunteer at Christmas before,
I'm sure we'd have people offended if we stopped doing that. But that
does not make a fruitcake delivery service an essential part of the
project administration.
Ideally we never need to migrate the forwarding service. We keep it
running on Oracle's servers as long as we can, and when they are shut
down, the forwarding is shut down. But we need a good sense of how
long that will be so we can give the users fair notice that the
service will be ended.
We also should figure out which addresses were used as official
project addresses, for requesting or reporting information, like
security vulnerabilities, etc. The set of official addresses should
be treated specially and likely will require forwarding longer term,
either to ooo-dev, ooo-private or ooo-security, as appropriate.
