incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: Extensions hosting
Date Fri, 06 Jan 2012 16:05:54 GMT
On Fri, Jan 6, 2012 at 10:55 AM, Ross Gardler
<> wrote:
> On 6 January 2012 15:35, Rob Weir <> wrote:
>> On Fri, Jan 6, 2012 at 10:08 AM, Ross Gardler
> ...
>>> As an IPMC member I would be concerned about a promise of breaking the
>>> Sourceforge stranglehold on the extensions site for the reasons I
>>> express above (ASF cannot benefit one organisation over another).
>>> However, I am only a single member of the IPMC and others may not have
>>> the same concerns.
>> "Stranglehold"?  I think that inflammatory term is not apt.   There
>> are other catalogs of OpenOffice extensions and templates.
> I agree my language is too strong. Even without considering the fact
> that there are other catalogues as you point out.
>>> That being said, I had assumed that shipped AOO code would point to a
>>> single, or even default site. Although the financial gain is not the
>>> same I see this as being comparable to Firefox shipping with Google as
>>> the default search engine. Mozilla can do this because of their legal
>>> structure, the ASF cannot.
>> I believe we're talking about the website, not the product.
> I seem to have been misunderstanding something about how the
> extensions manager works. My fault for making assumptions. I imagined
> it listing all available extensions within the application, However,
> having actually looked at it, I see I am actually presented with a
> single link to the extensions site. Sorry, I should have looked
> earlier, would have saved us some time.
> If that link were pointing at SF then I would be concerned me
> (remember we are talking about at the point of graduation). If it
> links to a website with multiple catalogues listed, or if there are
> multiple links within the product my concern is no longer valid. Such
> a modification is easy to make, even for 3.3.
> Thanks for putting me straight.
>> When we talked in the past about enabling the product to point to an
>> extension website, I think the thought was that we'd point to an
>> Apache catalog that contained only officially released extensions,
>> e.g., ALv2, QA'ed, voted on by PMC, etc.  That would be the safe thing
>> to do.  With a public, open extension repository we cannot really even
>> vouch for them being entirely free of malware.  It is really "as-is"
>> with a big disclaimer.  So it would probably not be appropriate for us
>> to point to them by default in the product.  (That was Dennis's
>> concern, as I understand it);.
> Yes, this is the long term strategy we've been discussing and I think
> it is a healthy goal. But does the AOO podling really want to limit it
> to ALv2?

Long term, I see something like this:

Product has a UI for extension repositories, with ability for user to
add, remove, enable or disable them.  Each repository is a URL.
Out-of-the-box, AOO releases would have only a single repository
enabled.  This would be the Apache one, containing only "released" (in
the Apache sense) extensions from this project, or maybe eventually
even other Apache projects.  We might have links to others in the
"extension repository" manager, but they would be disabled by default
and would have a warning when enabled.  There would be a UI for the
user to search across all enabled repositories, for keyboards, etc.
User can download/install extensions/templates from the UI. Maybe this
evolves to include clipart libraries, code snippets, and other
artifacts  eventually.

Honestly, to me the issue is not so much license, but vetting to
ensure users are not harmed.  We already see on the web today
companies that are using adulterated OpenOffice downloads to insert
adware onto machines.  The brand is strong enough to attract that.  If
we enable the outo-of-the-box install experience to allow direct
downloads/installs of non-Apache released extensions, then some users
will certainly be harmed.  Not all, but you can guarantee that there
will be malware in the repository.  The risk could be reduced by a
review/approval workflow controlled by the PMC, if we really wanted to
do that.

Of course, disabling the non-Apache repositories and requiring the
user to explicitly enable them doesn't really fix things either.  It
is more a point of making a clear separation between what is Apache
approved and what is not.

In some sense this is an iOS walled garden versus Android wild west question.


> Ross

View raw message