You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2016/08/31 16:26:38 UTC
RE: Independent Entity to Develop and Further AOO
One can always create an independent entity. It hasn't happened. By now, the odds are clearly that it will not. I suspect that folks who would pursue that avenue do not see a meaningful opportunity.
My considered opinion is that the greatest barrier is lack of a meaningful business/operation/funding model. In addition, there is an insufficient supply of developers having the capacity, capability, and will to provide material improvements to Apache OpenOffice. Whatever the pool might be, it is aging and shrinking for many reasons. The affliction that Apache OpenOffice suffers under in that respect also besets any organization set up to support the code, even with paid developers.
I also don't think working on Apache OpenOffice is much of a resume builder, since there is no other project like it and probably will never be. There are far easier projects to build an open-source reputation with, ones that build developer skills in areas where there is a growing and future demand.
Having suggested this much, I don't think it is meaningful to address how an external entity could "ensure they work on the AOO codebase using the ASF way."
If my appraisal is sound, that leaves us with the question about sustainability of the Apache OpenOffice project itself, and what the consequences of unsustainability are.
- Dennis
> -----Original Message-----
> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
> Sent: Monday, July 11, 2016 14:04
> To: dev@openoffice.apache.org
> Subject: RE: Independent Entity to Develop and Further AOO
>
> There is a bit to discuss about how "The entity should ensure they work
> on the AOO codebase using the ASF way" is workable or not. In
> particular, no such entity can direct the project at Apache or otherwise
> effectively govern it. More about that later.
>
> There is another option, summarized below. One might also consider this
> as a reality check. That is, if that is not feasible, it may be that no
> other arrangement is.
>
> > -----Original Message-----
> > From: Suminda Dharmasena [mailto:sirinath1978m@gmail.com]
> > Sent: Monday, July 11, 2016 00:23
> > To: marketing@openoffice.apache.org; dev@openoffice.apache.org
> > Subject: Independent Entity to Develop and Further AOO
> >
> > Hello,
> >
> > I am writing to see if the current AOO Dev team would like to create
> an
> > independent entity which can:
> >
> > - Do trainings
> > - Accept funds and have pay developers
> > - Write commercial books / online tutorials with sponsorship
> >
> > This can be used have paid developers working on the project. Maybe
> > initial
> > sponsorship can come from an organisation like Redhat, Pivotal or
> Micro
> > Focus if they are interested. Perhaps companies which used the code
> base
> > in
> > the past like IBM or Oracle.
> >
> > The entity should ensure they work on the AOO codebase using the ASF
> > way.
> >
> > Suminda
> [orcmid]
>
> AN ALTERNATIVE APPROACH
>
> Another way to interact and support Apache OpenOffice in terms of
> collaborative contributions is as follows.
>
> 1. Establish a downstream producer, TeamX (for example), that provides
> releases of derivative software based on Apache OpenOffice.
>
> 2. Assumption #1: The Apache License Version 2 (ALv2) is honored in the
> use of Apache OpenOffice source code. Apache trademark requirements are
> satisfied in any use as part of the branding of the downstream product.
>
> 3. Assumption #2: New code and modifications to the TeamX derivative
> are also under ALv2.
>
> 4. Open-Source Good Citizenship: The ALv2-licensed fixes and repairs
> are contributed back upstream to Apache OpenOffice. Components from
> other sources would, of course, be contributed upstream to those
> sources. Contributions and joint concerns might lead to use of the
> OpenOffice bugzilla as a coordination point.
>
> 5. Opportunity. The business model, organization, and governance of
> TeamX is not of concern to the ASF.
>
> 6. Opportunity. The Apache Software Foundation requirements beyond
> honoring of the ALv2 that govern Apache projects serving the public
> interest do not apply, although TeamX could operate in a harmonious
> manner.
>
> 7. Opportunity. So long as there is clear separation and no comingling
> in source-code files, TeamX is not constrained from also using code or
> components from other projects, such as those using licenses such as the
> MPL or, under appropriate conditions, something like LGPL2, with
> appropriate honoring of those licenses too. However, to avoid tainting
> of upstream source-code contributions back to Apache OpenOffice, there
> must be careful management of IP and reliance on code (source or binary)
> under non-ALv2 license (and ALv2 code which is not the original work of
> TeamX).
>
> 8. Opportunity. Depending on how close the operation of TeamX releases
> remains to that of Apache OpenOffice, especially at the beginning, one
> can rely on the Apache OpenOffice mediawiki and openoffice.org site in
> large measure, so long as there is no confusion. Also, the Apache
> OpenOffice Community Forums are more ecumenical in how they can provide
> forum support to OpenOffice.org-lineage ODF-supporting products. How
> confusion is avoided would need to be worked out, but this provides
> TeamX time to develop its own support as that ends up having unique
> requirements.
>
> This is not unlike how downstream organizations rely on Apache
> OpenOffice for specialized distributions (e.g., FreeBSD, OS/2, and
> Solaris). There are other Apache projects where the downstream
> ecosystem is quite robust and the key Apache project deliverable is the
> source-code release and not so much any end-user binary distributions.
>
> - Dennis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Posted by Kay Schenk <ks...@apache.org>.
On 08/31/2016 09:26 AM, Dennis E. Hamilton wrote:
> One can always create an independent entity. It hasn't happened. By now, the odds are clearly that it will not. I suspect that folks who would pursue that avenue do not see a meaningful opportunity.
>
> My considered opinion is that the greatest barrier is lack of a meaningful business/operation/funding model. In addition, there is an insufficient supply of developers having the capacity, capability, and will to provide material improvements to Apache OpenOffice. Whatever the pool might be, it is aging and shrinking for many reasons. The affliction that Apache OpenOffice suffers under in that respect also besets any organization set up to support the code, even with paid developers.
>
> I also don't think working on Apache OpenOffice is much of a resume builder, since there is no other project like it and probably will never be.
I think this all depends on what one's interests consists of. If you're
a C++ programmer looking for a challenging opportunity, Apache
OpenOffice might be just what you had in mind for a resume builder.
There are far easier projects to build an open-source reputation with,
ones that build developer skills in areas where there is a growing and
future demand.
>
> Having suggested this much, I don't think it is meaningful to address how an external entity could "ensure they work on the AOO codebase using the ASF way."
>
> If my appraisal is sound, that leaves us with the question about sustainability of the Apache OpenOffice project itself, and what the consequences of unsustainability are.
>
> - Dennis
>
>
>> -----Original Message-----
>> From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
>> Sent: Monday, July 11, 2016 14:04
>> To: dev@openoffice.apache.org
>> Subject: RE: Independent Entity to Develop and Further AOO
>>
>> There is a bit to discuss about how "The entity should ensure they work
>> on the AOO codebase using the ASF way" is workable or not. In
>> particular, no such entity can direct the project at Apache or otherwise
>> effectively govern it. More about that later.
>>
>> There is another option, summarized below. One might also consider this
>> as a reality check. That is, if that is not feasible, it may be that no
>> other arrangement is.
>>
>>> -----Original Message-----
>>> From: Suminda Dharmasena [mailto:sirinath1978m@gmail.com]
>>> Sent: Monday, July 11, 2016 00:23
>>> To: marketing@openoffice.apache.org; dev@openoffice.apache.org
>>> Subject: Independent Entity to Develop and Further AOO
>>>
>>> Hello,
>>>
>>> I am writing to see if the current AOO Dev team would like to create
>> an
>>> independent entity which can:
>>>
>>> - Do trainings
>>> - Accept funds and have pay developers
>>> - Write commercial books / online tutorials with sponsorship
>>>
>>> This can be used have paid developers working on the project. Maybe
>>> initial
>>> sponsorship can come from an organisation like Redhat, Pivotal or
>> Micro
>>> Focus if they are interested. Perhaps companies which used the code
>> base
>>> in
>>> the past like IBM or Oracle.
>>>
>>> The entity should ensure they work on the AOO codebase using the ASF
>>> way.
>>>
>>> Suminda
>> [orcmid]
>>
>> AN ALTERNATIVE APPROACH
>>
>> Another way to interact and support Apache OpenOffice in terms of
>> collaborative contributions is as follows.
>>
>> 1. Establish a downstream producer, TeamX (for example), that provides
>> releases of derivative software based on Apache OpenOffice.
>>
>> 2. Assumption #1: The Apache License Version 2 (ALv2) is honored in the
>> use of Apache OpenOffice source code. Apache trademark requirements are
>> satisfied in any use as part of the branding of the downstream product.
>>
>> 3. Assumption #2: New code and modifications to the TeamX derivative
>> are also under ALv2.
>>
>> 4. Open-Source Good Citizenship: The ALv2-licensed fixes and repairs
>> are contributed back upstream to Apache OpenOffice. Components from
>> other sources would, of course, be contributed upstream to those
>> sources. Contributions and joint concerns might lead to use of the
>> OpenOffice bugzilla as a coordination point.
>>
>> 5. Opportunity. The business model, organization, and governance of
>> TeamX is not of concern to the ASF.
>>
>> 6. Opportunity. The Apache Software Foundation requirements beyond
>> honoring of the ALv2 that govern Apache projects serving the public
>> interest do not apply, although TeamX could operate in a harmonious
>> manner.
>>
>> 7. Opportunity. So long as there is clear separation and no comingling
>> in source-code files, TeamX is not constrained from also using code or
>> components from other projects, such as those using licenses such as the
>> MPL or, under appropriate conditions, something like LGPL2, with
>> appropriate honoring of those licenses too. However, to avoid tainting
>> of upstream source-code contributions back to Apache OpenOffice, there
>> must be careful management of IP and reliance on code (source or binary)
>> under non-ALv2 license (and ALv2 code which is not the original work of
>> TeamX).
>>
>> 8. Opportunity. Depending on how close the operation of TeamX releases
>> remains to that of Apache OpenOffice, especially at the beginning, one
>> can rely on the Apache OpenOffice mediawiki and openoffice.org site in
>> large measure, so long as there is no confusion. Also, the Apache
>> OpenOffice Community Forums are more ecumenical in how they can provide
>> forum support to OpenOffice.org-lineage ODF-supporting products. How
>> confusion is avoided would need to be worked out, but this provides
>> TeamX time to develop its own support as that ends up having unique
>> requirements.
>>
>> This is not unlike how downstream organizations rely on Apache
>> OpenOffice for specialized distributions (e.g., FreeBSD, OS/2, and
>> Solaris). There are other Apache projects where the downstream
>> ecosystem is quite robust and the key Apache project deliverable is the
>> source-code release and not so much any end-user binary distributions.
>>
>> - Dennis
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
----------------------------------------
Kay Schenk
Apache OpenOffice
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Posted by toki <to...@gmail.com>.
On 31/08/2016 22:44, Dennis E. Hamilton wrote:
>> As a business model, it works for most of the Apache projects that emerged from Incubation, and stayed out of the Attic.
> I think that is the case because downstream producers, who get the support business,
contribute to their upstream framework or source-code distributor.
Back when Sun was running OOo, acceptance of patches from downstream
were very few and far between. Which is why Go-Oo was created.
When Oracle was running OOo, patches from downstream were more or less
uniformly rejected.
Part of the Apache Way is for code patches to be willingly contributed
by the individual or organization that wrote the patch. Code contributed
to other, similar software, even if appropriately licensed, won't make
the cut here. The code has to be directly submitted to the AOo code
repository.
Offhand,I don't know which OOo derivatives are using AOo as a baseline,
and which are using LibO as a baseline, and which are using neither as a
baseline, and which are using both as a baseline.
> What indication is there that any of that is working for Apache OpenOffice?
One issue, that was brought up back when AOo was a podling in
incubation, was that it had an over-reliance on developers from a single
company. As best as I can tell, it never broke out of that over-reliance
box.
And from https://db.apache.org/newproject.html are these telling quotes:
�Orphaned products. Products which have lost their corporate sponsor
(for whatever reason) do not make good candidates. These products will
lack a development community and won't have the support needed to
succeed under the DB umbrella�
and
�Reliance on salaried developers. DB has strong ties to the business
community. Many of our developers are encouraged by their employers to
work open source projects as part of their regular job. We feel that
this is a Good Thing, and corporations should be entitled to contribute
to open source, same as anyone else. However, we are wary of products
which rely strongly on developers who only work on open source products
when they are paid to do so. A product at DB must continue to exist
beyond the participation of individual volunteers. We believe the best
indicator of success is when developers volunteer their own time to work
open source projects.�
>Maybe if we stopped shipping binaries?
>How would that work for the individuals who seem to dominate our
download consumption?
One major difference between AOo and the rest of the projects supported
by The Apache Foundation, is that it focuses on consumers as end users,
not businesses as end users.
Whilst both Sun and, to much lesser extent, Oracle, sold enterprise
licenses for OOo, it was the consumer version that found the bugs. It
was the consumer version that drove product popularity. It was the
consumer that was reviewed in the trade press. The AOo binaries are the
consumer version.
Right now, AOo doesn't integrate with other software from The Apache
Foundation. It isn't something that an existing downstream distributor
of other Apache software can add to their catalogue, as a
supporting/additional feature/function/capability.
No doubt somebody will start muttering, "Apache Derby, Apache Cassandra,
Climate Workshop, etc." AOo is, at best, an optional client. It will
take major changes in AOo, for it to be the optimal client for those
projects.
>> OOo derivative, are not not that scarce. Somebody is providing tech support for those worksites.
> As far as I can tell, those downstream activities are invisible to the
project.
This is where having a list of OOo derivatives, and what their baseline
is, would be useful. In some respects, I'm a little surprised that there
aren't more AOo derivatives in the Android and iOS app stores.This is
where individual developers are still able to gain marketshare.
jonathon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Posted by Rory O'Farrell <of...@iol.ie>.
On Thu, 1 Sep 2016 09:58:04 -0700
"Dennis E. Hamilton" <de...@acm.org> wrote:
>
>
> > -----Original Message-----
> > From: Dr. Michael Stehmann [mailto:anwalt@rechtsanwalt-stehmann.de]
> > Sent: Wednesday, August 31, 2016 22:04
> > To: dev@openoffice.apache.org
> > Subject: Re: Independent Entity to Develop and Further AOO
> >
> > Am 01.09.2016 um 00:59 schrieb Simon Phipps:
> > > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton <
> > > dennis.hamilton@acm.org> wrote:
> > >
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: toki [mailto:toki.kantoor@gmail.com]
> > >>> Sent: Wednesday, August 31, 2016 11:30
> > >>> To: dev@openoffice.apache.org
> > >>> Subject: Re: Independent Entity to Develop and Further AOO
> > >>>
> > >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote:
> > >>>
> > >> I think that is the case because downstream producers, who get the
> > support
> > >> business, contribute to their upstream framework or source-code
> > distributor.
> > >>
> > >> What indication is there that any of that is working for Apache
> > >> OpenOffice? Maybe if we stopped shipping binaries? How would that
> > work
> > >> for the individuals who seem to dominate our download consumption?
> > >
> > >
> > > Since the "downstream" producers seem better equipped to deliver
> > signed and
> > > vulnerability-corrected binaries to non-specialist consumers on a
> > timely
> > > schedule, maybe delegating downloads to them would be a good option
> > for the
> > > project?
> >
> > Stopping shipping binaries would cause some negative effect for our
> > project, so it might be an option, but not best one.
> >
> > Binaries made by our community are essential for our QA.
> >
> > Without them we stand "with empty hands" in the public with negative
> > effects for our brand and image.
> >
> > Supporting our users by community members would break down.
> >
> > So the impact for the improvement of our commity would be tremendous, if
> > we "delegate" this tasks to a third party.
> [orcmid]
>
> I agree with Michael. Ceasing to provide builds from Apache OpenOffice but having a downstream producer provide them would be retirement of Apache OpenOffice in everything but name only.
I agree emphatically. Most OO users want to download and go - they have not the time or skills to build a version, which is not as trivial task, as frequenters of the dev ML will be aware.
RoryOF
>
> Also, the "downstream" in this thread refers to sellers of support who apparently package their own versions. We see no contributions back to the code base from any of those, whoever they might be.
>
> This is different than existence of forks and openoffice.org-descendant cousins who operate their own code base and support it, whoever those might be. While that might be disagreeable to some, it is in the spirit of open-source and the commitment of the Apache Software Foundation to serving the public interest. (The protection of the respective trademarks is a different matter with respect to avoiding confusion about the origin of the effort.)
>
>
> >
> > Kind regards
> > Michael
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: Independent Entity to Develop and Further AOO
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Dr. Michael Stehmann [mailto:anwalt@rechtsanwalt-stehmann.de]
> Sent: Wednesday, August 31, 2016 22:04
> To: dev@openoffice.apache.org
> Subject: Re: Independent Entity to Develop and Further AOO
>
> Am 01.09.2016 um 00:59 schrieb Simon Phipps:
> > On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton <
> > dennis.hamilton@acm.org> wrote:
> >
> >>
> >>
> >>> -----Original Message-----
> >>> From: toki [mailto:toki.kantoor@gmail.com]
> >>> Sent: Wednesday, August 31, 2016 11:30
> >>> To: dev@openoffice.apache.org
> >>> Subject: Re: Independent Entity to Develop and Further AOO
> >>>
> >>> On 31/08/2016 16:26, Dennis E. Hamilton wrote:
> >>>
> >> I think that is the case because downstream producers, who get the
> support
> >> business, contribute to their upstream framework or source-code
> distributor.
> >>
> >> What indication is there that any of that is working for Apache
> >> OpenOffice? Maybe if we stopped shipping binaries? How would that
> work
> >> for the individuals who seem to dominate our download consumption?
> >
> >
> > Since the "downstream" producers seem better equipped to deliver
> signed and
> > vulnerability-corrected binaries to non-specialist consumers on a
> timely
> > schedule, maybe delegating downloads to them would be a good option
> for the
> > project?
>
> Stopping shipping binaries would cause some negative effect for our
> project, so it might be an option, but not best one.
>
> Binaries made by our community are essential for our QA.
>
> Without them we stand "with empty hands" in the public with negative
> effects for our brand and image.
>
> Supporting our users by community members would break down.
>
> So the impact for the improvement of our commity would be tremendous, if
> we "delegate" this tasks to a third party.
[orcmid]
I agree with Michael. Ceasing to provide builds from Apache OpenOffice but having a downstream producer provide them would be retirement of Apache OpenOffice in everything but name only.
Also, the "downstream" in this thread refers to sellers of support who apparently package their own versions. We see no contributions back to the code base from any of those, whoever they might be.
This is different than existence of forks and openoffice.org-descendant cousins who operate their own code base and support it, whoever those might be. While that might be disagreeable to some, it is in the spirit of open-source and the commitment of the Apache Software Foundation to serving the public interest. (The protection of the respective trademarks is a different matter with respect to avoiding confusion about the origin of the effort.)
>
> Kind regards
> Michael
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Posted by "Dr. Michael Stehmann" <an...@rechtsanwalt-stehmann.de>.
Am 01.09.2016 um 00:59 schrieb Simon Phipps:
> On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton <
> dennis.hamilton@acm.org> wrote:
>
>>
>>
>>> -----Original Message-----
>>> From: toki [mailto:toki.kantoor@gmail.com]
>>> Sent: Wednesday, August 31, 2016 11:30
>>> To: dev@openoffice.apache.org
>>> Subject: Re: Independent Entity to Develop and Further AOO
>>>
>>> On 31/08/2016 16:26, Dennis E. Hamilton wrote:
>>>
>> I think that is the case because downstream producers, who get the support
>> business, contribute to their upstream framework or source-code distributor.
>>
>> What indication is there that any of that is working for Apache
>> OpenOffice? Maybe if we stopped shipping binaries? How would that work
>> for the individuals who seem to dominate our download consumption?
>
>
> Since the "downstream" producers seem better equipped to deliver signed and
> vulnerability-corrected binaries to non-specialist consumers on a timely
> schedule, maybe delegating downloads to them would be a good option for the
> project?
Stopping shipping binaries would cause some negative effect for our
project, so it might be an option, but not best one.
Binaries made by our community are essential for our QA.
Without them we stand "with empty hands" in the public with negative
effects for our brand and image.
Supporting our users by community members would break down.
So the impact for the improvement of our commity would be tremendous, if
we "delegate" this tasks to a third party.
Kind regards
Michael
Re: Independent Entity to Develop and Further AOO
Posted by Simon Phipps <si...@webmink.com>.
On Wed, Aug 31, 2016 at 11:44 PM, Dennis E. Hamilton <
dennis.hamilton@acm.org> wrote:
>
>
> > -----Original Message-----
> > From: toki [mailto:toki.kantoor@gmail.com]
> > Sent: Wednesday, August 31, 2016 11:30
> > To: dev@openoffice.apache.org
> > Subject: Re: Independent Entity to Develop and Further AOO
> >
> > On 31/08/2016 16:26, Dennis E. Hamilton wrote:
> >
> I think that is the case because downstream producers, who get the support
> business, contribute to their upstream framework or source-code distributor.
>
> What indication is there that any of that is working for Apache
> OpenOffice? Maybe if we stopped shipping binaries? How would that work
> for the individuals who seem to dominate our download consumption?
Since the "downstream" producers seem better equipped to deliver signed and
vulnerability-corrected binaries to non-specialist consumers on a timely
schedule, maybe delegating downloads to them would be a good option for the
project?
S.
RE: Independent Entity to Develop and Further AOO
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: toki [mailto:toki.kantoor@gmail.com]
> Sent: Wednesday, August 31, 2016 11:30
> To: dev@openoffice.apache.org
> Subject: Re: Independent Entity to Develop and Further AOO
>
> On 31/08/2016 16:26, Dennis E. Hamilton wrote:
>
> > One can always create an independent entity. It hasn't happened. By
> now, the odds are clearly that it will not.
>
> The Document Foundation is an independent entity, building upon the OOo
> 3.x code base.
>
> > My considered opinion is that the greatest barrier is lack of a
> meaningful business/operation/funding model.
>
> The business model is giving away the product, but selling support
> services. Sun almost understood that model. Oracle understands that
> model,but would rather throw away their product, than actually implement
> that model at the SOHO, or smaller scale.
>
> As a business model, it works for most of the Apache projects that
> emerged from Incubation, and stayed out of the Attic.
[orcmid]
I think that is the case because downstream producers, who get the support business, contribute to their upstream framework or source-code distributor.
What indication is there that any of that is working for Apache OpenOffice? Maybe if we stopped shipping binaries? How would that work for the individuals who seem to dominate our download consumption?
>
> > I also don't think working on Apache OpenOffice is much of a resume
> builder,
>
> What builds resumes is the specific contributions one makes. The
> specific project, be it AOo, No Man's Sky, BLEACHER, or anything else,
> is irrelevant.
>
> >since there is no other project like it and probably will never be.
>
> At least four other office suites utilize code from AOo. There are at
> least a thousand office suites for Android, and iOS, for which AOo
> development is a useful starting point.
>
> > If my appraisal is sound, that leaves us with the question about
> sustainability of the Apache OpenOffice project itself,
>
> Go back to the revenue generation model.
>
> Back in the 2003-2005 time frame, there were several organizations
> licensing their rebranded version of OOo for between US$20 and US$5,000
> per seat, per year. For various reasons, I quit tracking that data, and
> thus don't know what the current situation is.
>
> A decade ago, it was fairly difficult to find worksites of more than
> 1,000 that used OOo. Today, worksites of more than 5,000 users, using an
> OOo derivative, are not not that scarce. Somebody is providing tech
> support for those worksites.
[orcmid]
And how does any of that contribute to the development of Apache OpenOffice? As far as I can tell, those downstream activities are invisible to the project.
- Dennis
>
> jonathon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Independent Entity to Develop and Further AOO
Posted by toki <to...@gmail.com>.
On 31/08/2016 16:26, Dennis E. Hamilton wrote:
> One can always create an independent entity. It hasn't happened. By now, the odds are clearly that it will not.
The Document Foundation is an independent entity, building upon the OOo
3.x code base.
> My considered opinion is that the greatest barrier is lack of a meaningful business/operation/funding model.
The business model is giving away the product, but selling support
services. Sun almost understood that model. Oracle understands that
model,but would rather throw away their product, than actually implement
that model at the SOHO, or smaller scale.
As a business model, it works for most of the Apache projects that
emerged from Incubation, and stayed out of the Attic.
> I also don't think working on Apache OpenOffice is much of a resume builder,
What builds resumes is the specific contributions one makes. The
specific project, be it AOo, No Man's Sky, BLEACHER, or anything else,
is irrelevant.
>since there is no other project like it and probably will never be.
At least four other office suites utilize code from AOo. There are at
least a thousand office suites for Android, and iOS, for which AOo
development is a useful starting point.
> If my appraisal is sound, that leaves us with the question about sustainability of the Apache OpenOffice project itself,
Go back to the revenue generation model.
Back in the 2003-2005 time frame, there were several organizations
licensing their rebranded version of OOo for between US$20 and US$5,000
per seat, per year. For various reasons, I quit tracking that data, and
thus don't know what the current situation is.
A decade ago, it was fairly difficult to find worksites of more than
1,000 that used OOo. Today, worksites of more than 5,000 users, using an
OOo derivative, are not not that scarce. Somebody is providing tech
support for those worksites.
jonathon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org