On 07/30/2011 03:28 PM, Rob Weir wrote:
On Sat, Jul 30, 2011 at 5:25 PM, Kay Schenk<[email protected]> 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:[email protected]] 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
([email protected])<http://www.apache.org/>
([email protected])<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
