incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: [email] RE: [Discuss] ASF hosted openoffice.org email service [Was: Re: [Discussion] dev@openoffice.org]
Date Sun, 21 Aug 2011 14:18:59 GMT
On Sun, Aug 21, 2011 at 5:21 AM, Terry Ellison <terrye@apache.org> 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 name@openoffice.org 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
> TerryE@openoffice.org 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 TerryE@oo.o 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.

> //Terry
>
>

Mime
View raw message