Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)

Dennis, thanks for opening up this conversation.

As noted over the last few months, it has become obvious to the
board that AOO has not been a healthy project for some time.
Again, there are many, many reasons for this, and it doesn't
help to go into them here and now. The simple fact is that we are at
this point now, so what should be done?

First of all, let's address the elephant in the room: Some people
(mostly naysayers and people who love stirring up sh*t) will say that
"Apache had this coming" or that we were "stupid or arrogant" in
taking on this challenge. Doing so simply shows their own ignorance,
but it still stings I'm sure. Even if AOO had not done 1 single release,
the donation of the codebase *and the relicensing of said codebase to
the ALv2* has been a *significant* plus to the open office ecosystem.
This has allowed the other players in the game to have true IP
provenance, as well as the ability to relicense things, as LO did
almost immediately.

This is something MAJOR that many people will forget and ignore, but it
is something we should be proud of. As things proceed, and the haters
start (continue) hating, these are things we should remind ourselves
of.

Secondly, as alluded to above, we should prepare ourselves for the FUD,
the "AOO is dead" victory chants, the numerous anti-AOO and anti-Apache
spewings, etc... There are some who will use this as a self-serving
soapboxing opportunity, and warp the facts into some Bizarro alternate
universe history. We should be there to set the facts straight but
also resign ourselves to the fact that their voices will likely be louder
than ours.

Now, with that out of the way, here are my thoughts on retirement. I
have previously shared these but am doing so again.

What is obvious is that the AOO project cannot support, at the present
time, being an end-user focused effort. I would suggest we focus on not
being one, but instead being a framework or library that can be consumed
by actual end-user implementations.

This is similar to the initial thoughts behind our acceptance of AOO in
the 1st place: that AOO would form the basis/foundation/core-implementations
and others would build upon those to create more specialized and enhanced
OpenOffice alternatives; and since it was a core, a common shared core,
the expectation was that these alternatives would work together, in true
FOSS fashion, and AOO would see code and patches from these alternatives
in improving this core. As we all know, this did not happen, and instead
of sharing, these alternatives never contributed back.

So with all that being said, you may be asking, "Jim, if they didn't
contribute then why would the contribute now?". Let me answer that.

First of all, I think they saw us as competitors, rather than co-
operators. Some of this was due to bad-blood, and some of it was due
to stupid posturing on both sides. But the main reason why, imo, was
because we were also end-user. End users needed to make a *choice* between
AOO and SomethingElse. By no longer being an end-user application,
that goes away.

Secondly, part and parcel with this "pivot" is that we rename the project
to something more accurate to what our new function would be and we use
the AOO landing page to reference and redirect to the various OO
implementations out there. In fact, I would even suggest us considering
going further and redirecting AOO traffic to LO, so that people considering
"OpenOffice" get routed to the LO site (either automatically or via some
click/OK interface).

With these 2 changes, as obvious olive branches, I think we will
see all players in the OO development eco-system be willing contributors
to the new project. And this will give the new project a new lease
on life.

Cheers!


> On Sep 1, 2016, at 7:37 PM, Dennis E. Hamilton <orcmid@apache.org> wrote:
> 
> Here is what a careful retirement of Apache OpenOffice could look like.
> 
>              A. PERSPECTIVE
>              B. WHAT RETIREMENT COULD LOOK LIKE
>                 1. Code Base
>                 2. Downloads
>                 3. Development Support
>                 4. Public-Project Community Interfaces
>                 5. Social Media Presence
>                 6. Project Management Committee
>                 7. Branding
> 
> A. PERSPECTIVE
> 
> I have regularly observed that the Apache OpenOffice project has limited
capacity for sustaining the project in an energetic manner.  It is also my
considered opinion that there is no ready supply of developers who have the
capacity, capability, and will to supplement the roughly half-dozen
volunteers holding the project together.  It doesn't matter what the reasons
for that might be.
> 
> The Apache Project Maturity Model,
>
<http://community.apache.org/apache-way/apache-project-mat...>,
identifies the characteristics for which an Apache project is expected to
strive. 
> 
> Recently, some elements have been brought into serious question:
> 
> QU20: The project puts a very high priority on producing secure software.
> QU50: The project strives to respond to documented bug reports in a timely
manner.
> 
> There is also a litmus test which is kind of a red line.  That is for the
project to have a PMC capable of producing releases.  That means that there
are at least three available PMC members capable of building a functioning
binary from a release-candidate archive, and who do so in providing binding
votes to approve the release of that code.  
> 
> In the case of Apache OpenOffice, needing to disclose security
vulnerabilities for which there is no mitigation in an update has become a
serious issue.
> 
> In responses to concerns raised in June, the PMC is currently tasked by the
ASF Board to account for this inability and to provide a remedy.  An
indicator of the seriousness of the Board's concern is the PMC been requested
to report to the Board every month, starting in August, rather than
quarterly, the normal case.  One option for remedy that must be considered is
retirement of the project.  The request is for the PMC's consideration among
other possible options.  The Board has not ordered a solution. 
> 
> I cannot prediction how this will all work out.  It is remiss of me not to
point out that retirement of the project is a serious possibility.
> 
> There are those who fear that discussing retirement can become a
self-fulfilling prophecy.  My concern is that the project could end with a
bang or a whimper.  My interest is in seeing any retirement happen
gracefully.  That means we need to consider it as a contingency.  For
contingency plans, no time is a good time, but earlier is always better than
later.
> 
> 
> B. WHAT RETIREMENT COULD LOOK LIKE
> 
> Here is a provisional list of all elements that would have to be addressed,
over a period of time, as part of any retirement effort.   
> 
> In order to understand what would have had to happen in a graceful process,
the assumption below is that the project has already retired.
> 
> Requests for additions and adjustments to this compilation are welcome.
> 
> 1. CODE BASE
> 
>    1.1 The Apache OpenOffice Subversion repository where code is maintained
has been moved to "The Attic."  Apache Attic is an actual project,
<http://attic.apache.org/>.  The source code would remain
> available and could be checked-out from Subversion by anyone interested in
making use of it.  There is no means of committing changes.
> 
>    1.2 Apache Externals/Extras consists of external libraries that are
relied upon by the source code but are not part of the source code.  These
were housed on SourceForge and elsewhere.  (a) They might have been archived
in conjunction with the SVN (1.1).  (b) They might be identified in a way
that someone attempting to build from source later on would be able to work
with later versions of the external dependencies.  There are additional
external dependencies that might have become obsolete.
> 
>    1.3 Build Dependencies/Tool Chains.  The actual construction of the
released binaries depends on particular versions of specific tools that are
used for carrying out builds of binaries from the source.  The dependencies
as they last were used are identified in a historical location.  Some of the
tools and their use become obsolete over time.
> 
>    1.4 GitHub Mirror.  For the GitHub Mirror of the Apache OpenOffice SVN
(a) pull requests are not accepted.  (b) Continuation of the presence of the
GitHub repository might be shut down at some point depending on GitHub policy
and ASF support.
> 
> 2. DOWNLOADS
> 
>    2.1 The source code releases, patches, and installable binaries are all
retained in the archive system that is already maintained.  There are no
further additions.
> 
>    2.2 The downloading of full releases is supported on the SourceForge
mirroring system.  There are no new downloads.  How long until SourceForge
retires its support for downloads is not predictable (and see 4.3).  
> 
>    2.3 The Apache OpenOffice Extensions and Templates system is an
independent arrangement hosted and curated on SourceForge.  Whether and how
long the download service is preserved by SourceForge is not predictable.
> 
>    2.4 The mechanism for announcing updates to installed versions of
OpenOffice binaries is adjusted to indicate that (a) particular versions are
no longer supported.  (b) For the latest distribution(s), there may be advice
to users about investigating still-supported alternatives.  
> 
> 3. DEVELOPMENT SUPPORT
> 
>    3.1 The Apache OpenOffice Bugzilla is mirrored in The Attic.  The
Bugzilla is read-only and preserved for historical purposes.
> 
>    3.2 The Pootle materials used for the development of localizations are
exported and archived.
> 
>    3.3 The Confluence Wiki operated by the project is preserved in a
read-only state:<https://cwiki.apache.org/confluence/display/OOOUSERS/>. 
> 
>    3.4 The commits@ and issues@ mailing lists are shut down although
archived.
> 
> 4. PUBLIC PROJECT-COMMUNITY INTERFACES
> 
>    4.1 All public discussion mailing lists are shut down.  They are all
archived and accessible from The Attic.  
> 
>    4.2 The dev@ list was the last to shut down, having been used during
orchestration of the retirement.
> 
>    4.3 The http://openoffice.org site is static and uneditable.  The CMS
functions for contribution to the site are disabled.  Over the course of
retirement, key pages of the site were updated to reflect the retirement
activity and to eventually end some of the functions, such as information on
how to contribute, how to obtain the software, how to obtain help, branding
requirements, etc.  
> 
>    4.4 The Wikimedia subsite of openoffice.org is read-only and static.  No
contributions or edits can be made.  At some point, the Wikimedia server will
need to be shut down and (a) the server is shutdown/moved with openoffice.org
indicating that the wiki is unavailable.  (b) Only a static form of the pages
is provided. (c) Alternative hosting and rebranding is achieved.
> 
>    4.5 The OpenOffice Community Forums were semi-autonomous.  (a) The
server is retired.  (b) The site is rehosted and rebranded by agreement with
the Apache OpenOffice project and the ASF.  
> 
> 
> 5. SOCIAL MEDIA PRESENCE
> 
>    5.1 The Apache Planet OpenOffice Blog is terminated with the
announcement that Retirement is complete.
> 
>    5.2 The Twitter account is terminated.
> 
>    5.3 Any Facebook page under control of the project is closed.
> 
>    5.4 The announce@ list is terminated and archived with the announcement
of Retirement completion.
> 
> 
> 6. PROJECT MANAGEMENT COMMITTEE
> 
>    6.1 With completion of the retirement, the private@ and security@
openoffice.org lists were shutdown (although archived as are all such
lists).
> 
>    6.2 The Project Management Committee is disbanded and the Chair is
relieved.
> 
>    6.3 There is no longer any identified operation for continuation of the
project except as specified for The Attic.
> 
> 
> 7. BRANDING
> 
>    7.1 With the cessation of releases, it is made widely known that
official releases other than the last ones provided by the project are not
the work of Apache OpenOffice and any claimed association, justification for
charge of fees and for carrying of advertising are not in support of the
Apache OpenOffice project.  This notification will also be made to those
organizations that carry offerings to the contrary (e.g., eBay).
> 
>    7.2 There is no point of contact, other than branding@ apache.org, for
request to make use of the brands.
> 
>    7.3 There is no active attention to preservation of the trademarks
related to Apache OpenOffice.  (a) Inappropriate use of Apache and its
symbols in names of offerings will be defended when brought to the attention
of branding@.  (b) Uses of OpenOffice, Open Office, openoffice.org and other
similarities without attribution to Apache are not addressed.
> 
>                                    *** end of the list as of 2016-09-01
***
> 
>