Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openoffice.apache.org
Reply-To: <dennis.hamilton@acm.org>
From: "Dennis E. Hamilton" <dennis.hamilton@acm.org>
To: <dev@openoffice.apache.org>
Cc: "'Suminda Dharmasena'" <sirinath1978m@gmail.com>
References: <CAAfFNYEBbXaTj5-qVy7V8Uj7uA3wCyo6O0fsHG7ESpmTG4qO3Q@mail.gmail.com> <003501d1dbb7$b23daea0$16b90be0$@acm.org>
In-Reply-To: <003501d1dbb7$b23daea0$16b90be0$@acm.org>
Subject: RE: Independent Entity to Develop and Further AOO
Date: Wed, 31 Aug 2016 09:26:38 -0700
Organization: NuovoDoc
Message-ID: <011501d203a4$73f52050$5bdf60f0$@acm.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQGdY194nEDe7IhtV3c+Rv6j4bGsBQHO3uzGoL4GqqA=
Content-Language: en-us
archived-at: Wed, 31 Aug 2016 16:27:20 -0000

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

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
>=20
> 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.
>=20
> 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.
>=20
> > -----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]
>=20
> AN ALTERNATIVE APPROACH
>=20
> Another way to interact and support Apache OpenOffice in terms of
> collaborative contributions is as follows.
>=20
>  1. Establish a downstream producer, TeamX (for example), that =
provides
> releases of derivative software based on Apache OpenOffice.
>=20
>  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.
>=20
>  3. Assumption #2: New code and modifications to the TeamX derivative
> are also under ALv2.
>=20
>  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.
>=20
>  5. Opportunity.  The business model, organization, and governance of
> TeamX is not of concern to the ASF.
>=20
>  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.
>=20
>  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).
>=20
>  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.
>=20
> 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.
>=20
>  - Dennis
>=20
>=20
> ---------------------------------------------------------------------
> 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