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

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

Dennis E. Hamilton-2
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-maturity-model.html>, 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 ***



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Dave Fisher
Hi Dennis,

I don't have objections to this topic, but I feel I need to make a few suggestions before this thread is either ignored or a confused mess.

(1) a long, official policy statement like this is best put into a wiki page where many can edit it and it can be an easy discussion and not a confused email mess that is started with something that is tl:dr. The maturity model was recently developed by the comdev participants on the wiki and email
Effectively. This document needs to be developed in the same way.

(2) why is this cross posted to private and DEV? To do so implies that there is some other non-open discussion in parallel. You and I have run into unexpected results from this strange cross posting practice of yours (hi Simon)

(3) I think that working towards being able to release rather than patch as Patricia has suggested is our best way to solve the security issue. The quick patch is not much faster and has been proven to be more of a challenge then kick starting the broken build process.

Regards,
Dave

Sent from my iPhone

> On Sep 1, 2016, at 4:37 PM, Dennis E. Hamilton <[hidden email]> 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-maturity-model.html>, 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 ***
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Pedro Giffuni
In reply to this post by Dennis E. Hamilton-2
Hmm ... the discussion sounds a bit like Brexit ...

With the important difference that it is now evident that Brexit
didn't have a plan.

Having a retirement plan is important for our users and for the ASF
and while I think the discussion is sane and important I think we should
focus now on the next release. It is clear to me that
even if AOO were to be retired, we still have to push out a
new release mainly because we do have stuff that should see
the light of a release.

For the release we are certainly seeing some deficiencies:

- Can we responsibly deliver AOO 4.2.0 for the Mac? If the base/java
issue is as serious as it sounds and since we don't have much developer
feedback or even a buildbot, we may have to release 4.2.0 with a Mac
version!

After the release there are certainly much more things to discuss.

Pedro.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Dennis E. Hamilton-2
In reply to this post by Dave Fisher
[BCC to PMC]

> -----Original Message-----
> From: Dave Fisher [mailto:[hidden email]]
> Sent: Thursday, September 1, 2016 19:27
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
>
> Hi Dennis,
>
> I don't have objections to this topic, but I feel I need to make a few
> suggestions before this thread is either ignored or a confused mess.
>
> (1) a long, official policy statement like this is best put into a wiki
> page where many can edit it and it can be an easy discussion and not a
> confused email mess that is started with something that is tl:dr. The
> maturity model was recently developed by the comdev participants on the
> wiki and email
> Effectively. This document needs to be developed in the same way.
[orcmid]

Good idea.  I see no reason not to follow that path.  This was my thought-starter.

I was not intending an official policy statement.  It is a discussion request, with some background information for perspective.  (Oh, I had to use orcmid@ a.o because of the BCC, since that's how I am on private@ though.  I see the confusion I causes doing that.)


>
> (2) why is this cross posted to private and DEV? To do so implies that
> there is some other non-open discussion in parallel. You and I have run
> into unexpected results from this strange cross posting practice of
> yours (hi Simon)
[orcmid]

It was not cross-posted.  I intentionally did not do that.  The BCC was to private@, just as I am doing now.  It was an easy way to provide a heads-up to the PMC for a discussion to notice on dev@, since some don't siphon through all of the dev@ material regularly.  It is not on dev@ as a cross-posting.


>
> (3) I think that working towards being able to release rather than patch
> as Patricia has suggested is our best way to solve the security issue.
> The quick patch is not much faster and has been proven to be more of a
> challenge then kick starting the broken build process.
[orcmid]

That would be interesting to determine.  Now that we have released a Hotfix, I think we can get it done more quickly in the future, but it is certainly not as good as simply offering the community a full update to install.

That is a different subject though.  It would be great to have that outcome.

>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Sep 1, 2016, at 4:37 PM, Dennis E. Hamilton <[hidden email]>
> 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
> >
[ ... ]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Phillip Rhodes
In reply to this post by Dennis E. Hamilton-2
Wow, just wow.  I have to say, I think even broaching this topic is a
mistake.  "Self-fulfilling prophecy"? Not even that, it'll be a "3rd party
fulfilling prophecy" as soon as this hits the press.  There are a lot of
people out there who seem to have it in for AOO and have for a while... now
you *know* there will be a headline appearing in the next week, reading
"Apache OpenOffice Mulls Retirement" or "AOO Begins To Wind Down", etc.
Yeah, it's crappy journalism, but it's almost 100% certain to happen.  And
that's just going to dampen enthusiasm even more.

I wish I could say I had a magic bullet of an answer for how to get things
moving again, but I don't.  But I don't think opening a discussion about
retirement and giving AOO's enemies more ammunition is a strong tactical
move.


Phil


This message optimized for indexing by NSA PRISM

On Thu, Sep 1, 2016 at 7:37 PM, Dennis E. Hamilton <[hidden email]>
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-maturity-model.html>,
> 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
> ***
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

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

Phillip Rhodes
In reply to this post by Dave Fisher
> (3) I think that working towards being able to release rather than patch
> as Patricia has suggested is our best way to solve the security issue. The
> quick patch is not much faster and has been proven to be more of a
> challenge then kick starting the broken build process.
>


Forgive me for being a little behind.  What is broken in the build process?
Technical problem, or process issue, or other or what?


Phil
Reply | Threaded
Open this post in threaded view
|

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

Dennis E. Hamilton
In reply to this post by Phillip Rhodes
> -----Original Message-----
> From: Phillip Rhodes [mailto:[hidden email]]
> Sent: Thursday, September 1, 2016 21:16
> To: [hidden email]; [hidden email]
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
>
> Wow, just wow.  I have to say, I think even broaching this topic is a
> mistake.  "Self-fulfilling prophecy"? Not even that, it'll be a "3rd
> party
> fulfilling prophecy" as soon as this hits the press.  There are a lot of
> people out there who seem to have it in for AOO and have for a while...
> now
> you *know* there will be a headline appearing in the next week, reading
> "Apache OpenOffice Mulls Retirement" or "AOO Begins To Wind Down", etc.
> Yeah, it's crappy journalism, but it's almost 100% certain to happen.
> And
> that's just going to dampen enthusiasm even more.
>
> I wish I could say I had a magic bullet of an answer for how to get
> things
> moving again, but I don't.  But I don't think opening a discussion about
> retirement and giving AOO's enemies more ammunition is a strong tactical
> move.
[orcmid]

You're right Phil, it is not meant to be a tactical (or even strategic) move in some sort of adversarial situation.

How else can we work through these difficulties, and understand our options as a community?  

Being a project of the Apache Software Foundation brings with it some rather unique requirements for operation in the public interest and operating in the open with our community, including the public that relies on Apache OpenOffice software.

I don't know any way to accomplish that in a way that outsiders can't spin however they like.  We need the engagement and many eyes and thoughts of our community, as reflected here on dev@.  

What alternative do you see?

>
>
> Phil
>
>
> This message optimized for indexing by NSA PRISM
>
> On Thu, Sep 1, 2016 at 7:37 PM, Dennis E. Hamilton <[hidden email]>
> 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
> >
[ ... ] >


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Phillip Rhodes
>
>
> What alternative do you see?
>
>
>
There's no particular reason that I can see, that AOO shouldn't be able to
produce secure software, issue releases and
do all of those other things.  We've done it in the past (and yeah, I feel
guilty about saying "we" since I haven't been very active. Mea culpa), and
it's not like the project caught bubonic plague or something.  Yeah, I know
a lot of people prefer to contribute to LO and not AOO, and that losing the
people IBM was paying was a big hit.   But I can't help but think there's a
way to get more people involved and contributing here.  So I'd rather see
discussion around "how do we attract additional
contributors (or fix whatever other problems we have)?"  than talk about a
"retirement plan."  I really do think that if people start putting a lot of
energy into that, it will rob even more energy from the project.

Or maybe there are other options that could be considered, even if only as
interim steps.  Somebody mentioned something about a problem making Mac
releases. OK fine, let's drop Mac support for now.  Maybe that frees up
some energy for other things.  OK, radical suggestion and probably won't be
met with a lot of support, but the point is to say, let's think outside the
box a little and see if there are some other ideas we could adopt.



Phil
Reply | Threaded
Open this post in threaded view
|

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

Dennis E. Hamilton
In reply to this post by Phillip Rhodes


> -----Original Message-----
> From: Phillip Rhodes [mailto:[hidden email]]
> Sent: Thursday, September 1, 2016 21:23
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
>
> > (3) I think that working towards being able to release rather than
> patch
> > as Patricia has suggested is our best way to solve the security issue.
> The
> > quick patch is not much faster and has been proven to be more of a
> > challenge then kick starting the broken build process.
> >
>
>
> Forgive me for being a little behind.  What is broken in the build
> process?
> Technical problem, or process issue, or other or what?
>
[orcmid]

This is off-topic for this thread, but it may be helpful in illustrating why the Board wants to know what the project's considerations are with respect to retirement and in particular, with regard to avoiding the situation I will now recount.

The remark about a patch has to do with CVE-2016-1513, with our advisory at
<http://www.openoffice.org/security/cves/CVE-2016-1513.html>.

The vulnerability, and a proof of concept were reported to the project on 2016-10-20 as Apache OpenOffice 4.1.2 was going out the door.  

We had figured out the source-code fix in March.  

On June 7, the reporter was concerned about sitting on the disclosure any longer and gave us a June deadline, proposing to disclose even though we had not committed to an AOO update.  We were sitting on the fix because we didn't want to give anyone ideas when they saw it applied to the source code unless there was a release in the works.  

We negotiated a disclosure extension to July 21.  Part of that agreement was our working to create a hotfix instead of attempting to work up a full maintenance release (e.g., a 4.1.3).  On July 21 we issued an advisory that disclosed existence of the vulnerability without offering any repaired software.  

We had the corrected shared library at the time of disclosure, but had not tested much for possible regressions with it.  Also, instructions needed to be written.  General Availability of the Hotfix, 4.1.2-patch1, was on August 30, after more testing, QA of the instructions and the fix, and adding a couple of localizations.  The QA period did turn up a couple of glitches and improvements to the instructions and also included scripts to simplify the task for Windows users.

There are two prospects for this year: a 4.1.3 maintenance release for some important maintenance-only items and the 4.2.0 feature release.  In either case it is likely that an update of any kind will be a year since the release of Apache OpenOffice 4.1.2.

If anyone wants to look into the issues of producing releases, I suggest you confirm the 4.1.2 release by compiling it from the source archive using the available build instructions and see how well you can replicate the released binary for the same platform.  Where we fall the most short is having enough folks who can do this for Windows and MacOSX, covering almost 95% of our user base [;<).

>
> Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Dennis E. Hamilton
In reply to this post by Phillip Rhodes


> -----Original Message-----
> From: Phillip Rhodes [mailto:[hidden email]]
> Sent: Thursday, September 1, 2016 21:49
> To: [hidden email]; Dennis Hamilton <[hidden email]>
> Subject: Re: [DISCUSS] What Would OpenOffice Retirement Involve? (long)
>
> >
> >
> > What alternative do you see?
> >
> >
> >
> There's no particular reason that I can see, that AOO shouldn't be able
> to
> produce secure software, issue releases and
> do all of those other things.  We've done it in the past (and yeah, I
> feel
> guilty about saying "we" since I haven't been very active. Mea culpa),
> and
> it's not like the project caught bubonic plague or something.  Yeah, I
> know
> a lot of people prefer to contribute to LO and not AOO, and that losing
> the
> people IBM was paying was a big hit.   But I can't help but think
> there's a
> way to get more people involved and contributing here.  So I'd rather
> see
> discussion around "how do we attract additional
> contributors (or fix whatever other problems we have)?"  than talk about
> a
> "retirement plan."  I really do think that if people start putting a lot
> of
> energy into that, it will rob even more energy from the project.
>
> Or maybe there are other options that could be considered, even if only
> as
> interim steps.  Somebody mentioned something about a problem making Mac
> releases. OK fine, let's drop Mac support for now.  Maybe that frees up
> some energy for other things.  OK, radical suggestion and probably won't
> be
> met with a lot of support, but the point is to say, let's think outside
> the
> box a little and see if there are some other ideas we could adopt.
>
>
[orcmid]

I think you will be heartened that there is just such an effort underway and many think that will be the answer.

Are you one of those who can "put a lot of energy into it?"  Do you know where you'd direct that energy to come up with likely candidates for becoming more involved?

With regard to interim steps, it is striking to realize that, as low as the MacOSX population is, it is almost double our Linux user base [;<).




>
> Phil


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Andrea Pescetti-2
In reply to this post by Dennis E. Hamilton-2
Dennis E. Hamilton wrote:
> One option for remedy that must be considered is retirement of the project.  ...
> There are those who fear that discussing retirement can become a self-fulfilling prophecy.

This is becoming too much. There are other options. Namely, a new
release will invalidate the prerequisites for your mail. Out of respect
for the people who volunteered to steer a new release we should be
supportive of them instead of playing the "what if" game.

Still, thank you for showing that retirement would be much more
difficult than making a new release! So the best (my favorite) option is
now clearly to make a release happen.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Dr. Michael Stehmann-2
In reply to this post by Dennis E. Hamilton-2
Hello,

the situation as I see it (I am no developer) is, that we need
"developers, developers, developers, developers ... ".

So why not "going public" and ask the Free Software community for help?

That means to illustrate, why AOO is important for the progress of Free
Software, and to describe our present situation and the benefits of
helping us.

But there are IMO some conditions, we have to set before going public:

1. We need a contact person for volunteers and also for enterprises,
which wants to collaborate with us.

2. We need mentors for newbies.

IMO we have to start such a campaign in 2016.

Just my 2 cents.

Kind regards
Michael


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jörg Schmidt-2
Hello,

> From: Dr. Michael Stehmann [mailto:[hidden email]]

> the situation as I see it (I am no developer) is, that we need
> "developers, developers, developers, developers ... ".

> [...]

This is not wrong, but ...

Developers will participate primarily in projects which remain publicly well.

If we look at LibreOffice and compare:
LibreOffice, that is *good* (not more) software and *excellent* public relations.
OpenOffice, that is *exellent* software and *pretty bad* public relations.

We need to understand evaluate software as the normal user: their first scale is essential to public presentation of a software, and only secondarily the purely technical characteristics of a software.

We need to understand the difference between a software such as the Apache Webserver https://httpd.apache.org/ (a software for experts) and OpenOffice (a software for end users).


The problem of AOO is a Specific:

many people who have worked for OOo (.org!) done their way and OOo has accepted the results and the work integrated into the project.

The operation of Apache is too formalistic for such people, for example, for the local German community of OpenOffice. At the time of OpenOffice.org many helpers did their part, because there were few organizational hurdles.

Example:
I have been working for many years for the PrOOo-box (http://www.prooo-box.org), at the very beginning was that a purely private project, BUT it was always a project to support OpenOffice.
The community of OOo has recognized this and has the PrOOo-box as part of OpenOffice accepted (more precisely, as part of the German community of OO).

In Apache, however we are only "third-party". No question, the classification as "third-party" is formally correct, because it conforms to the rules of Apache, but it inhibits the practical work.

*It is urgently needed to give local communities more autonomy, which would forward the work.*


Let me say for my own:
I work more than 10 years for OpenOffice (.org and Apache) and I am all the time loyal to OpenOffice. I am now a committer of Apache, and of course I respect the rules of Apache ... BUT in practice, there are task where you have to act, and it is not always time to comply with formalities.

example:
Last month, the PrOOo-box was published in a large German IT magazine [1]. This was a great success for the PrOOo-box. I would have preferred if it had been a success for OpenOffice.

What i mean?
We (the german community, and all local communities) need the opportunity to speak locally for OpenOffice. It is undisputed that this must be coordinated with the international Apache OpenOffice community, but this coordination can only be done in the form of a frame, not for every single little action, because we have no time for the coordination of every detail.


Greetings
Jörg


[1]
https://www.idgshop.de/PC-WELT-Plus-09-2016.htm?websale8=idg&pi=1-6058&ci=2-5278



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Roberto Galoppini-2
Quick top note: to avoid multiple mails I'll comment this and the others
messages here.

First, I totally agree with Andrea, let's focus on what needs to be done,
it's inappropriate at best to discuss anything related to the shutdown at
this time. Yet if someone enjoys the exercise of style that's ok, but
please don't ask people doing the work to stop doing the right thing for
engaging in this game. Enough said.

Second, as Michael says we need more developers. When I was at SourceForge
we have been often able to help projects here and there to find more
developers, I'm confident Dave Brondsema (Apache Allura VP) can help us to
get one or more calls out via forums, blog and newsletters.

On the same line we could ask some help to get the news out via Slashdot, I
guess at the end of the day after all the blame it would be a news to let
people know the community is still there, and some how growing. As far as
we're ok with the Slashdot style of communication, we would probably have
good chance to be covered.


On Friday, 2 September 2016, Jörg Schmidt <[hidden email]> wrote:

> Hello,
>
> > From: Dr. Michael Stehmann [mailto:[hidden email]
> <javascript:;>]
>
> > the situation as I see it (I am no developer) is, that we need
> > "developers, developers, developers, developers ... ".
>
> > [...]
>
> This is not wrong, but ...
>
> Developers will participate primarily in projects which remain publicly
> well.
>
> If we look at LibreOffice and compare:
> LibreOffice, that is *good* (not more) software and *excellent* public
> relations.
> OpenOffice, that is *exellent* software and *pretty bad* public relations.
>
> We need to understand evaluate software as the normal user: their first
> scale is essential to public presentation of a software, and only
> secondarily the purely technical characteristics of a software.
>
> We need to understand the difference between a software such as the Apache
> Webserver https://httpd.apache.org/ (a software for experts) and
> OpenOffice (a software for end users).
>
>
> The problem of AOO is a Specific:
>
> many people who have worked for OOo (.org!) done their way and OOo has
> accepted the results and the work integrated into the project.
>
> The operation of Apache is too formalistic for such people, for example,
> for the local German community of OpenOffice. At the time of OpenOffice.org
> many helpers did their part, because there were few organizational hurdles.
>
> Example:
> I have been working for many years for the PrOOo-box (
> http://www.prooo-box.org), at the very beginning was that a purely
> private project, BUT it was always a project to support OpenOffice.
> The community of OOo has recognized this and has the PrOOo-box as part of
> OpenOffice accepted (more precisely, as part of the German community of OO).
>
> In Apache, however we are only "third-party". No question, the
> classification as "third-party" is formally correct, because it conforms to
> the rules of Apache, but it inhibits the practical work.
>
> *It is urgently needed to give local communities more autonomy, which
> would forward the work.*
>
>
> Let me say for my own:
> I work more than 10 years for OpenOffice (.org and Apache) and I am all
> the time loyal to OpenOffice. I am now a committer of Apache, and of course
> I respect the rules of Apache ... BUT in practice, there are task where you
> have to act, and it is not always time to comply with formalities.
>
> example:
> Last month, the PrOOo-box was published in a large German IT magazine [1].
> This was a great success for the PrOOo-box. I would have preferred if it
> had been a success for OpenOffice.
>
> What i mean?
> We (the german community, and all local communities) need the opportunity
> to speak locally for OpenOffice. It is undisputed that this must be
> coordinated with the international Apache OpenOffice community, but this
> coordination can only be done in the form of a frame, not for every single
> little action, because we have no time for the coordination of every detail.


> Having been part of OOo in the old times I remember well the local
> chapters, wonder if that would really collide with the Apache way, though.
> Speak locally not only should be possible, but also praised. I understand
> the "third party" thing might be more complex to handle, still we could
> evalute on a case by case basis what we could do. Even if it takes time,
> maybe it's not a waste of it.


> Roberto


>
>
>
> Greetings
> Jörg
>
>
> [1]
> https://www.idgshop.de/PC-WELT-Plus-09-2016.htm?
> websale8=idg&pi=1-6058&ci=2-5278
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> <javascript:;>
> For additional commands, e-mail: [hidden email]
> <javascript:;>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Dr. Michael Stehmann-2
In reply to this post by Dr. Michael Stehmann-2
Hello,

our discussion became public:

http://www.linux-magazin.de/content/view/full/106599

This shows a public interest. So "going public" seems not to difficult.

Kind regards
Michael




signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jim Jagielski
In reply to this post by Dennis E. Hamilton-2
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 <[hidden email]> 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-maturity-model.html>, 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 ***
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Dr. Michael Stehmann-2
Am 02.09.2016 um 14:14 schrieb Jim Jagielski:

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

If AOO is not an end-user focused project a lot of people will leave
this community because they will be useless. People who are doing
end-user support, who are doing end-user documentation and are doing
what we call "marketing" etc.

Also people, who build binaries are obsolet. Only coders will be needed
and I don't know, whether all remained will stay under that conditions.

I don't see a great difference between that way and a retirement.

The first way might be the "Apache way", but it is definitely not the
way for and of the OpenOffice community.

Just my 2 cents.

Kind regards
Michael





signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jörg Schmidt-2
In reply to this post by Jim Jagielski
> From: Jim Jagielski [mailto:[hidden email]]

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

You're absolutely right.


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

-1

OpenOffice is not LibreOffice!

never we forget how members of OpenOffice (for example, Rob Weir) were insulted by
TDF representatives.



Greetings,
Jorg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Patricia Shanahan
In reply to this post by Dr. Michael Stehmann-2
On 9/2/2016 5:52 AM, RA Stehmann wrote:

> Am 02.09.2016 um 14:14 schrieb Jim Jagielski:
>
>>
>> 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.
>>
>
> If AOO is not an end-user focused project a lot of people will leave
> this community because they will be useless. People who are doing
> end-user support, who are doing end-user documentation and are doing
> what we call "marketing" etc.
>
> Also people, who build binaries are obsolet. Only coders will be needed
> and I don't know, whether all remained will stay under that conditions.

I certainly won't stay. I am interested in keeping the end user
application viable. The library/framework idea does not interest me at all.

This discussion has a serious self fulfilling prophecy downside. The
less ASF's commitment to AOO, the less my commitment is. I had been
thinking of buying a Mac and learning to do builds on it. That is an
investment of time, energy, and a small amount of money. Why do it, if
AOO is just going to get shut down anyway?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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

Jim Jagielski
In reply to this post by Dr. Michael Stehmann-2
Yes, I would assume that many existing people would leave.

But, as I mentioned, I would assume (hope) that many people
would join, and many of those would be from others in the
entire OO eco-system.

Your reply seems to suggest that with the current status of AOO,
maintaining an end-user focus is possible. Current evidence,
unfortunately, makes that somewhat questionable.

The current status-quo is untenable and unacceptable. Change
needs to happen. I suggested one route, nothing more, nothing
less.

> On Sep 2, 2016, at 8:52 AM, RA Stehmann <[hidden email]> wrote:
>
> Am 02.09.2016 um 14:14 schrieb Jim Jagielski:
>
>>
>> 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.
>>
>
> If AOO is not an end-user focused project a lot of people will leave
> this community because they will be useless. People who are doing
> end-user support, who are doing end-user documentation and are doing
> what we call "marketing" etc.
>
> Also people, who build binaries are obsolet. Only coders will be needed
> and I don't know, whether all remained will stay under that conditions.
>
> I don't see a great difference between that way and a retirement.
>
> The first way might be the "Apache way", but it is definitely not the
> way for and of the OpenOffice community.
>
> Just my 2 cents.
>
> Kind regards
> Michael
>
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

1234