incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <>
Subject Refactoring the brand: Apache ooo + (was branding)
Date Sat, 30 Jul 2011 18:37:50 GMT
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 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 atop all of it is over-constraining
and also confusing, even though the result may be unrecognizably different at the end-user

 - Dennis


[Disclaimer.  This inspired my thinking but any misunderstanding of what Roy was thinking
is mine and mine alone.]

> -----Original Message-----
> From: Roy T. Fielding [] 
> Sent: Wednesday, July 27, 2011 09:51
> [ ... quoted by permission ]
> Subject: Re: branding
> [ ... ]
> BTW, my personal preference is to call our product Apache OOo and leave the
> 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,
> ....Roy T. Fielding, Director, The Apache Software Foundation
>    (  <>
>    (    <>

I am not invested in the history or passion around 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
to a place where it is a business-as-usual continuation of the now-stalled effort.  

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

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.  

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

View raw message