incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: Extensions hosting
Date Fri, 06 Jan 2012 11:12:11 GMT
On 1/5/12 2:57 PM, Rob Weir wrote:
> 2012/1/5 Jürgen Schmidt<>:
>> 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 GPL,
>> 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 repo
>> 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 extensions
>> ...
> 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, 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.

i think i have understand the model quite well ;-)

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

that is exactly what i have tried to explain several times

> 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.
fine that is more that we have now but what i also tried to explain that 
we have such a format already

> b) An encoding of the metadata, in XML.

we have it already

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

nice idea, under which Url do you would like do collect all the repos?

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

also nice

> 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 agree and that is what i have also tried to explain ;-)

But the extended meta data, and the multiple repos support in the office 
are all long term ideas and not for 3.4, correct?


>> 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 hosting
>> 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 are
>> 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<>    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
>>>> 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.  SF 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.  We 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.  Trusted 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.  We 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.  To that
>>>> 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.  Our Site Operations team will do teh
>>>> work and oversee the operations for you as we do other services.  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.  Drupal will be hosted on our project web service, serving
>>>> your existing domain via a VHOST.  Standard 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.  We anticipate this
>>>> migration would involve a week of planning and preparation, followed
>>>> by a week of migration and pre/post-migration communications.  We'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.  We would also be able to cross promote the software titles
>>>> 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 community for many years -- he will continue to
>>>> be your point-of-contact.  If 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.  I 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.  To 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.  So 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.  Feel
>>>> 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

View raw message