Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: 98.139.213.137 is neither permitted
 nor denied by domain of kay.schenk@gmail.com)
Message-ID: <4E35D47F.6030308@gmail.com>
Date: Sun, 31 Jul 2011 15:17:35 -0700
From: Kay Schenk <kay.schenk@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11
MIME-Version: 1.0
To: ooo-dev@incubator.apache.org
Subject: Re: Refactoring the brand: Apache ooo + OpenOffice.org? (was
 re:OpenOffice.org
 branding)
References: <008a01cc4ee7$ca79e5e0$5f6db1a0$@acm.org>
	<4E3476BB.8050506@gmail.com>
 <CAP-ksoiMVvxYJcMnJObA+JJndfC5-wrJki0MV0ZM8TwFbYLBMg@mail.gmail.com>
In-Reply-To: 
 <CAP-ksoiMVvxYJcMnJObA+JJndfC5-wrJki0MV0ZM8TwFbYLBMg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


On 07/30/2011 03:28 PM, Rob Weir wrote:
> On Sat, Jul 30, 2011 at 5:25 PM, Kay Schenk<kay.schenk@gmail.com>  wrote:
>>
>>
>> On 07/30/2011 11:37 AM, Dennis E. Hamilton wrote:
>>>
>>> On another list, I saw a comment from Roy Fielding that resonated
>>> with me.  Others have mentioned it, but not here on ooo-dev.
>>>
>>> My interpretation is that we could have Apache ooo as the identifier
>>> of the core Apache project built on what we factor out of the Oracle
>>> grant, leaving OpenOffice.org as a web site and a family of
>>> distributions and support for end-user and adopter/integrator
>>> activities that reach out beyond the development of a buildable
>>> open-source code base.
>>
>> This seems like a GREAT idea to me assuming it can be "done" vis a vis
>> current conditions -- the Apache way, etc. Also see below
>>
>
>
> That has been the plan since the start.  We eventually have an
> openoffice.apache.org web site that has the project-facing website and
> services, like source repositories, dev lists, work by translators,
> documentation, etc.  This is the web site where those who make OOo
> work, the project community.

Well OK, at some point I got very confused by what this meant I guess.
Should I take this remark openoffice.apache.org will be primarily the 
stop off for what I'll call "code developers"?

>
> Then we have http:///www.openoffice.org, which remains the end-user
> facing portal, the entry way to downloads, to support, to templates
> and extensions, etc.

Right, OK, but again, where will this and many other ancillary 
openoffice.org sites (like the forums etc.) actually live?

>
> There are some services that have dual personalities, like bugzilla,
> which is used by users as well as those on the project development
> side.

-- more below....

>
> This would not be an attempt to create an artificial division between
> the project community and the users.  I'm very sensitive to that.  But
> in this space, we really need an extremely easy-to-use,  slee, sexy,
> consumer-friendly portal for end users. This is the face of the
> project to millions of current and potential users.  We should have
> hooks to draw them into the project community, for those with further
> interest.  But we can't scare them initially with the bare-bones
> standard Apache look and feel project site.
>
>>>
>>> I think we should consider that attempting to put OpenOffice.org atop
>>> all of it is over-constraining and also confusing, even though the
>>> result may be unrecognizably different at the end-user level.
>>>
>>> - Dennis
>>>
>>> MORE THOUGHTS BELOW THE QUOTATION
>>>
>>> [Disclaimer.  This inspired my thinking but any misunderstanding of
>>> what Roy was thinking is mine and mine alone.]
>>>
>>>> -----Original Message----- From: Roy T. Fielding
>>>> [mailto:fielding@gbiv.com] Sent: Wednesday, July 27, 2011 09:51 [
>>>> ... quoted by permission ] Subject: Re: OpenOffice.org branding
>>>>
>>>> [ ... ]
>>>>
>>>> BTW, my personal preference is to call our product Apache OOo and
>>>> leave the OpenOffice.org website as a joint forum and
>>>> redistribution site for all variations of the suite, docs,
>>>> tutorials, etc.  However, such decisions are typically made by the
>>>> people doing the work.
>>>>
>>>> Cheers,
>>
>> yes... +1
>>
>>>>
>>>> ....Roy T. Fielding, Director, The Apache Software Foundation
>>>> (fielding@apache.org)<http://www.apache.org/>
>>>> (fielding@gbiv.com)<http://roy.gbiv.com/>
>>>>
>>>
>>> MORE THOUGHTS
>>>
>>> I am not invested in the history or passion around OpenOffice.org as
>>> an ongoing development.  My perspective is as someone who works from
>>> the open standards and architectural perspective.  So I beg your
>>> forbearance if I have been insensitive to the history and the
>>> familiarity that there is in how things have been done over the
>>> years.  It is not my intention to offend but to see what we can see
>>> by thinking outside of the box.
>>>
>>> I trust it is clear to all of us that it will be unlikely that we can
>>> somehow revive OpenOffice.org to a place where it is a
>>> business-as-usual continuation of the now-stalled effort.
>>>
>
> Not business as usual.  Business better than usual.  But this is not
> something for arguing.  It is for doing.
>
>>> Furthermore, my attention is on the suitability of Apache ooo as a
>>> reference implementation with respect to ODF, with less emphasis on
>>> what it takes to continue OpenOffice.org a desirable and thriving
>>> software distribution.  I'm in favor of that.  It is not what my
>>> attention is on.  So this is not a balanced perspective.
>>>
>
>
> And why can't we do both?  Is there some reason why an application
> cannot both be a good implementation of ODF and also be a thriving
> product?  There are not mutually exclusive outcomes.
>
>
>>> Here are some loosely-conceived thoughts.  I don't have a clear or
>>> specific picture.  But I think the conceptual separation of ooo and
>>> OpenOffice.org is an opportunity that might unfreeze us from trying
>>> to move ahead under one giant lump.
>>
>> I agree...but...
>>
>>>
>>> I favor the idea of separating the "pure Apache-way" project effort
>>> and from the OpenOffice.org identity and "brand" as a broader
>>> umbrella for all of the variations that go into making end-user
>>> distributions, providing documentation materials, end-user support,
>>> and especially the various native-language efforts that are part of
>>> the OpenOffice.org ecosystem.
>>
>
> I've heard this idea put forward by LibreOffice supports as well.  The
> brand name of OpenOffice.org is very strong.  The web site gets a lot
> of traffic.  Far more than libreoffice.org.  Far more than
> symphony.lotus.com.  I think we'd all love a link from that website.
> Who wouldn't? If you look at other Apache projects you see that they
> are quite liberal about providing links to distributions of downstream
> consumers, including other ports, distros and derived applications.
> This comes with a disclaimed that these are not official Apache
> releases, but it does help give these other projects some greater
> visibility and "link love".  See, for example, this Subversion page:
>
> http://subversion.apache.org/packages.html
>
> As you can see, there is also some degree of co-branding.  So there is
> TortoiseSVN, uberSVN, visualSVN, etc
>
> I've always assumed we'd do something similar for Apache OpenOffice,
> provide links to other releases.  And if someone wants to call their
> release "SuperDuper OpenOffice" or whatever, then we'd handle that
> request via the normal process for Apache branding discussions.
>
>
>> HOW to do this? I mean from a practical, pragmatic perspective. How will
>> continued existence of what we might see as the "end user" OpenOffice.org
>> architecture (servers, administration architecture) be carried out? What
>> will we use, where will it be housed, how will it be administered it and who
>> will finance it? I am QUITE concerned about the existence of the current
>> site (on kenai). Maybe I missed it, but I haven't seen a "drop dead" for
>> removal of OpenOffice.org from this platform.
>>
>
> We've had discussions on the list on migration, some details here
> (look at the website transfer row of the table):
>
> https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning

Yes, I know about this and have contributed to this but it doesn't 
really answer my question...where do we go?

The "user facing" sites are itemized in

https://cwiki.apache.org/confluence/display/OOOUSERS/OOo-Sitemap

assuming you exclude development, distribution, and api (maybe others 
related to direct development).

What is the suggestion to place this architecture elsewhere?


>
>>>
>>> I also see separation as rather easy because at the moment we are
>>> using "ooo" for these lists, for the podling's SVN repository branch,
>>> for the two wikis, for the Apache Extras (although that has forked
>>> already [;<), etc.
>>
>> um....see my last comments. Easy from a philosophical standpoint, but not
>> necessarily from a practical one.
>>
>>>
>>> I favor the idea of a cleaner separation of the development of the
>>> core ODF reference-implementation aspects from wider variations that
>>> are typical and appropriate for a production-usable productivity
>>> suite.  A distribution will have incidental and discretionary
>>> provisions that aren't particularly indicative of the "reference"
>>> aspects and have not been the subject of standardization.
>>>
>>> Important Context: There is wide latitude for discretion in the ODF
>>> specifications and even wider latitude for user-interface,
>>> non-UI-based processors, etc., that are not the subject matter of the
>>> ODF specification at all.  It would be good to remove confusion
>>> around that.  Also, a reference implementation, to the extent it is
>>> usable in practice, should not be taken as being in any sense
>>> compelling with regard to anything but its conformant support for the
>>> file format itself.  A reference implementation that can be operated
>>> needs to do something in discretionary areas.  The incidental and
>>> discretionary choices should be soundly done and well-narrated.  But
>>> there must be no suggestion that the approach to such incidental and
>>> discretionary cases reflect requirements of ODF.  The user interface
>>> and its functionality is not subject matter for the ODF specification
>>> as it now exists.  One wants ways to produce features of the format.
>>> One wants ways to deal with provisions of the format in any input
>>> that is processed.  But the gap from input to user presentation and
>>> interaction and from there to output is not prescribed in the ODF
>>> specification, nor are mappings between different formats and the
>>> treatment of different formats as defaults.
>>>
>>> I'm not sure how much the technology transfer/deployment would work
>>> from Apache ooo to OpenOffice.org and that is something we need to
>>> figure out.
>>
>> Can you elaborate on what you mean by this? I'm confused.
>>
>>   When we have the code and the collateral artifacts in
>>>
>>> hand, our inspection may provide insight into how we can get rolling
>>> and also understand how the development can be modularized in a
>>> productive way.
>>>
>>> - Dennis
>>>
>>>
>>
>> good discussion...
>>
>>>
>>>
>>
>> --
>> ------------------------------------------------------------------------
>> MzK
>>
>> "If you can keep your head when all others around you
>>   are losing theirs - maybe you don't fully understand
>>   the situation!"
>>                             -- Unknown
>>

-- 
------------------------------------------------------------------------
MzK

"If you can keep your head when all others around you
  are losing theirs - maybe you don't fully understand
  the situation!"
                             -- Unknown