Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <4F05985A.5080806@googlemail.com>
References: 
 <CAKQbXgB3SNrNEPPej6N1W2DuaAetNye6LxAGtRE+Qyy+yhxoRQ@mail.gmail.com>
	<CAKQbXgCSvUm4_Jsp_xS3E++N+u_u0nv7-Qi_SK4GirPq2wR6=Q@mail.gmail.com>
	<4F05985A.5080806@googlemail.com>
Date: Thu, 5 Jan 2012 08:57:48 -0500
Message-ID: 
 <CAP-ksogZ9-cfG+3qth1PWsNJG=GvG_K+k6DxiwHgeNAYOiTzTA@mail.gmail.com>
Subject: Re: Extensions hosting
From: Rob Weir <robweir@apache.org>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2012/1/5 J=C3=BCrgen Schmidt <jogischmidt@googlemail.com>:
> On 1/5/12 12:12 PM, Ross Gardler wrote:
>>
>> As a separate point in this thread I should also point out that the
>> ASF has some experience of dealing with off-site repository providers.
>> Not all of it good. Most of the problems have been a result of lack of
>> planning and lack of adequate protection of the trademarks involved.
>>
>> All those cases (to my knowledge) have now reached satisfactory
>> states. I imagine the Board will be keen to see that The PPMC has
>> considered the kinds of terms that will be offered to third party
>> sites with respect to trademark usage. My recommendation would be to
>> simply state that no use beyond those approved by existing ASF policy
>> will be required.
>>
>> I also suggest that if the PPMC wants to take Sourceforge up on the
>> offer that it is made clear to all parties that this will not be the
>> "official" AOO extensions repository. Only the ASF will host official
>> Apache services. However, this does not mean that the AOO site and
>> product cannot link out to an SF provided repository.
>>
>> Remember also that the ASF cannot do anything that benefits a single
>> organisation more than any other. Therefore, any agreement with
>> Sourceforge cannot be exclusive. There must be opportunities for
>> others to offer similar services if they want to put the effort into
>> doing so.
>
>
> I think that is fair enough. I see it in the way that SF comes first to
> offer their help and help us to solve a problem with general hosting of G=
PL,
> LGPL etc. extensions that we can't host in an official ASF repo. We can
> probably rename it and find a way to make clear that it is a supported re=
po
> but not the official one (long term when we an official ASF repo).
>
> And the proposed index only solution is not satisfying for me because of =
the
> explained reasons (missing hosting of the binary extension packages or
> templates). But I would like to learn more about it and especially how it
> should be maintained, the frontend how users would register their extensi=
ons
> ...

Let's take an example of the general pattern, with blogs. Blogs are
content, hosted all over the web, on millions of different sites.
Sometimes they are hosted together, in one place, by blog hosting
sites, like Blogger or Wordpress.com, and in other cases they are
hosted by the individual owners on their own websites.  There are many
different providers of blogging software as well.  But they all agree
on some basic standards:  HTML for the content, and RSS or Atom for
syndication.  RSS and Atom (and you only really need one of them.  The
fact that there are two is an historical accident) are the glue that
contexts the content stores (blogs) with other services. For example,
Google Blog search, News Readers, mobile apps like Pulse, aggregator's
for "Planet" websites, etc.  By separating the storage of the content
from the advertising of the content, you open up a whole new set of
possibilities.

So the model that I think is attractive for extensions and templates is:

1) The actual repositories for the templates can be done anywhere.  We
don't specify how they are stored.  It could be SourceForge, Google
Code, here at Apache, on the author's own personal website, wherever.
We don't specify the user interface, the account model, the
interactions the extension author has with the repository site.  These
details are all the concern of the repository owner. Let them compete
for app developers based on the services they provide and how easy
they make it for app developers.

Of course, Apache can host a repository as well, but I think
considerations of license and release policy will lead us,in the end,
to only host extensions that are actual releases of the project.

2) What we do specify are:

a) The metadata related to extensions.  For example, name of
extension, version, author, website, short description, screen shot,
language, versions of OpenOffice supported, license, and of course,
the URL to download.

b) An encoding of the metadata, in XML.

c) A mechanism for advertising the extensions hosted at a given
repository.   If we just base this on Atom, we'll be able to reuse a
lot of existing libraries, so that might be a good start.

3) It would then be the responsibility of the repository hosts to
provide feeds of available extensions per the above specifications.
This would be optional.   Similarly, you can have a "blog" today, but
provide no RSS or Atom feed.  But by doing so you shut yourself out of
the larger ecosystem that is enabled by having feeds.  For larger
repository hosts, like SourceForge, these feeds could be automatically
generated from the repository data.  But even a small personal website
with just 1 or 2 extensions should be able to hand-author a correct
feed.

4) We then have one or more aggregators of extension and template
metadata.  These would be fed by a collection of feed URL's, submitted
by repository  hosts.  The aggregator would periodically fetch updated
metadata.  The aggregator would then have a user-facing UI for
searching, filtering, rating, reviewing, and downloading, extensions.
Apache could host one that was open to all feed submissions.

5) This model enables other things, like automatically sending a
Twitter tweet when a new extension is added, or having a "Planet AOO
Extensions" that posts the descriptions of new templates as they come
in, etc.  Could even put that in a section of our website.

6) The feed mechanism could also work well for in-product use, to have
the ability to browse one or more repositories for extensions.  Maybe
out-of-the-box, we only point to the official Apache extension
repository, including officially released extensions.  But the user
can add (or enable) additional repositories. This could be similar to
how some Linux distros deal with 3rd party packages, where you start
with just supported packages, but can enable additional sources.

>
> I haven't seen a long term solution that would solve our problem for
> graduation. How do we want address for example a template repo with hosti=
ng
> capabilites for templates?
>
> We can use the existing implementation of the repos (extensions and
> templates) and can remove all content and allow ALv2 licensed stuff only.
> But then we have again to answer the question of hosting binaries or
> templates. Do we want support it, do we have the resources (storage,
> bandwidth)?
>
> As we have discussed earlier it is fine to have several repos and one
> official ASF repo. Support of multiple repos (not yet implemented) that a=
re
> configurable in the office. Especially when we think of internal repos in=
 a
> closed enterprise environment...
>
> If it won't work with SF we can revert it. For me it seems at least worse=
 a
> try because we have limited resources anyway, still enough to do and any
> kind of help is welcome, or not?
>
> It's again a situation where the existing solution doesn't fit well in
> Apache because of allowing copyleft licensed stuff as well. But it is
> somewhat important for the overall eco-system. I hope we can find a
> satisfying solution and i think multiple repos can be a solution.
>
> Juergen
>
>
>>
>> Ross
>>
>> On 3 January 2012 15:51, Ross Gardler<rgardler@opendirective.com> =C2=A0=
wrote:
>>>
>>> As the community know Gav, in his role at infrastructure@ has
>>> undertaken to stabilise and migrate the AOO extensions code to ASF
>>> infrastructure. His work has been progressing and he remains committed
>>> to completing this.
>>>
>>> However, as some know Sourceforge made an offer to help via our
>>> private list. At the time they did not want to discuss this topic in
>>> public for a number of reasons. I've had a couple of chats with
>>> Roberto Gallopini and Jeff Drobick in order to help them understand
>>> why the ASF prefers to host all services for its projects. In response
>>> SF have tailored their offer of support.
>>>
>>> I relayed the outline of our conversations to the infrastructure team
>>> who have asked me to have the AOO project provide some feedback, via a
>>> board report, on what problems the AOO project forsee for the
>>> extensions site and what options are available, if possible a
>>> recommendation for an optimal solution should also be made. Note that
>>> we can submit something out of cycle if we want, the next full report
>>> is not due till March.
>>>
>>> The reason infra@ have escalated to board@ is probably that we need to
>>> figure out a long term solution for the AOO project and that solution
>>> is heavily influenced by ASF policy. Any solution that we are
>>> currently considering will have an impact on the AOO extensions site
>>> and/or on ASF policy.
>>>
>>> The current situation, as I understand it, is that the board have
>>> given permission for the extensions site to be managed by infra during
>>> incubation. The problem of distributing content under licences other
>>> than Apache is not seen to be a problem during the incubation process.
>>> Beyond incubation the board has delegated responsibility to the
>>> Incubator PMC. I don't believe that particular discussion has been
>>> started yet.
>>>
>>> Gav tells us that he has been thinking about making the extensions
>>> site an index site, thus allowing the extensions to be housed
>>> elsewhere (apache-extras, sourceforge, google code, github, FooBar
>>> corporation or wherever). This would neatly bypass the licence
>>> problem. Open source extensions needing hosting could go to
>>> apache-extras while commercially licensed extensions would need to
>>> provide their own hosting.
>>>
>>> An alternative is to work with a third party willing to help. I've
>>> copied below the text of a mail outlining the SF proposal. You will
>>> note that they are keen to ensure that we don't get locked into the SF
>>> services. Nevertheless, one of the reasons the ASF hosts its own
>>> services is to avoid exposing us to unmanageable risk.
>>>
>>> I have no reason to believe SourceForge have anything other than good
>>> intentions in making this offer. SF has been supporting open source
>>> for a very long time. It is backed at the highest level (Jeff is
>>> President and CEO) and I believe Roberto is known within the
>>> OpenOffce.org community. However, many aspects of this will be outside
>>> of the control of the AOO project, despite SFs real attempts to
>>> mitigate our concerns relating to this.
>>>
>>> Please note that the timescales Jeff outlines are unrealistic given
>>> that we need to seek board input before being able to ensure the AOO
>>> project makes the right decision. =C2=A0SF want to move quickly, but I
>>> don't think we need to be rushed into making a decision.
>>>
>>> Once you've digested and debated the offer from Sourceforge the
>>> community needs to come up with a couple of paragraphs indicating a
>>> desired route forwards and reasons for it. I will try and attend the
>>> appropriate board meeting in order to answer any questions that arise.
>>>
>>> Please be imaginative in your planning for the future. The optimal
>>> solution might be some combination of ASF and SF offerings.
>>>
>>> Note Roberto Gallopini has joined this list and is ready to make any
>>> clarifications necessary. I've also made Gav aware of this post so
>>> that he can answer any questions we have about what infra@ are able to
>>> do.
>>>
>>> Thanks,
>>> Ross
>>>
>>> --- COPIED PROPOSAL ---
>>>
>>> I'm glad we had a chance to talk last week - exciting times for Open
>>> Office as the product and community transition into the ASF.
>>>
>>> For over a decade, SourceForge has been committed to advancing the
>>> open source software community. =C2=A0We host over 300,000 projects and=
 are
>>> visited by over 40 MM users per month for free, secure, and fast
>>> downloads of open source software. =C2=A0Trusted and reliable download
>>> delivery is an important part of our service, with over 4 million
>>> downloads per day and 2 PB from our mirror network each month. =C2=A0We=
 are
>>> committed to helping OSS projects scale and grow.
>>>
>>> Based on our discussions, we understand there are a few things you are
>>> solving for as part of the Open Office Incubation effort:
>>> Supporting a diverse licensing terms for Open Office extensions, that
>>> may not all comply with the Apache OSS policy;
>>> Stabilizing your Drupal OO Extensions site and ensuring high
>>> availability and download bandwidth without cost
>>> Expanding both the developer base who will move into working on the
>>> Apache framework as well as adoption of the Open Office product and
>>> extensions.
>>> We think we can help and that there would be mutual benefit. =C2=A0To t=
hat
>>> end, we propose the following for your consideration:
>>>
>>> 1.) Stabilize the your OO Extensions Drupal instance by moving the it
>>> and all services to SourceForge. =C2=A0Our Site Operations team will do=
 teh
>>> work and oversee the operations for you as we do other services. =C2=A0=
To
>>> your community the directory will look the same and extension and
>>> template files will move to SourceForge's globally-distributed
>>> download mirror network where we can ensure reliable, scalable
>>> delivery. =C2=A0Drupal will be hosted on our project web service, servi=
ng
>>> your existing domain via a VHOST. =C2=A0Standard infrastructure
>>> (monitoring, backups, etc.) and service levels (99.9% availability
>>> target) apply.
>>>
>>> These SourceForge services will be provided gratis, and without
>>> lock-in -- you are open to change your mind later. =C2=A0We anticipate =
this
>>> migration would involve a week of planning and preparation, followed
>>> by a week of migration and pre/post-migration communications. =C2=A0We'=
re
>>> prepared to commence this work the next week if provided your approval
>>> and support.
>>>
>>> 2.) Once stabilized, we will work with you on a timeline to evaluate
>>> and execute a migration from Drupal 5 to Drupal 7.
>>>
>>> Allowing us to host the Extensions community will solve the license
>>> challenges - or at least give you time to work through a longer term
>>> solution. =C2=A0We would also be able to cross promote the software tit=
les
>>> to the development community as well - so perhaps expand not only your
>>> user base but developers.
>>>
>>> Roberto (our Sr. Director of Business Development) has been involved
>>> in the OpenOffice.org community for many years -- he will continue to
>>> be your point-of-contact. =C2=A0If we secure the go-ahead this week, we
>>> will start on Tuesday next week and expect to be complete by 1/15 with
>>> step 1. =C2=A0I have asked our head of Site Ops to oversee the
>>> implementation and he'll partner up with your technical folks to
>>> ensure the hosting transition goes well.
>>>
>>> Our motivation here is quite simple, it is all part of our mission to
>>> help Open Source Software initiatives succeed. =C2=A0To that end,
>>> SourceForge and Geeknet Media are able to fund these services and make
>>> them free to the community through advertising largely on the download
>>> and directory pages. =C2=A0So there won't ever be a charge back to your
>>> community and we are able to reinvest in R&D on our developer tools as
>>> well.
>>>
>>> We look forward to hearing back from you this week if possible. =C2=A0F=
eel
>>> free to forward this on to whomever you would like in terms of getting
>>> to an aligned decision.
>>>
>>> I wish you a happy new year!
>>>
>>> --
>>> Thank you,
>>> Jeff
>>>
>>> --- End of copied text ---
>>> --
>>> Ross Gardler (@rgardler)
>>> Programme Leader (Open Development)
>>> OpenDirective http://opendirective.com
>>
>>
>>
>>
>