Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of dennis.hamilton@acm.org
 designates 75.98.160.130 as permitted sender)
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: "OOo-dev Apache Incubator " <ooo-dev@incubator.apache.org>
Cc: "'Roy T. Fielding'" <fielding@gbiv.com>
Subject: Refactoring the brand: Apache ooo + OpenOffice.org?  (was
 re:OpenOffice.org branding)
Date: Sat, 30 Jul 2011 11:37:50 -0700
Organization: NuovoDoc
Message-ID: <008a01cc4ee7$ca79e5e0$5f6db1a0$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcxO5zGCgCTCHp7nQqaaiPry5Kn6dA==
Content-Language: en-us

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.

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]=20
> Sent: Wednesday, July 27, 2011 09:51
> [ ... quoted by permission ]
> Subject: Re: OpenOffice.org branding
>=20
> [ ... ]
>=20
> 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.
>=20
> Cheers,
>=20
> ....Roy T. Fielding, Director, The Apache Software Foundation
>    (fielding@apache.org)  <http://www.apache.org/>
>    (fielding@gbiv.com)    <http://roy.gbiv.com/>
>=20
=20
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. =20

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. =20

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.

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 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.=20

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.

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. =20

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.  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