I recommend that any extensions the product will automatically install, whether or not at user-controlled option, should come from ASF-hosted servers.
Anything else should be caveat emptor, whether at OSUOSL or elsewhere, and neither downloadable nor installable from within a running instance of any AOO deliverable or its installer. I favor [option 1] with critical bits moved to an [option 2] ASF-hosted resource, and any [option 5] developed over time as appropriate and folks apply themselves to it, perhaps after leaving incubation. - Dennis -----Original Message----- From: Rob Weir [mailto:[email protected]] Sent: Tuesday, November 29, 2011 08:07 To: [email protected]; [email protected] Subject: Extensions and templates [ ... ] We currently have an extensions repository and a template repository, kindly hosted by OSUOSL (http://osuosl.org/) on our subdomains: extensions.services.openoffice.org templates.services.openoffice.org These repositories carry 3rd extensions and templates under a wide variety of licenses, including a mix of open source licenses, copyleft and non-copyleft, as well as non-open source licensed "freeware" and "trial-ware" packages. Because of these various licenses, I think it is unlikely to be something that we could host at Apache, even in just binary form. So what are our options? ==Option 1: Remain at OSUOSL== We could remain with OSUOSL hosting. However, the existing site is very unstable. For this approach to be practical we'd need a volunteer with Drupal skills to work with OSUOSL to diagnose what is wrong and to restore stability to these services. Maybe some sight maintenance, upgrades or tuning is sufficient? I think this would be the ideal short-term solution at the very least. ==Option 2: Move Critical extensions to stable host== This is more a back up plan if nothing else works in the AOO 3.4 timeframe. There are a handful of critical extensions that many users will want access to, such as spell checking dictionaries. If OSUOSL is not stable when 3.4 is released, then we will have many thousands of very frustrated users. So with this option we copy the critical extensions to Apache-Extras and point 3.4 users to that. [ ... ] ==Option 5: Re-architect the Repositories== This is the option I personally favor for long term. The downside of what we have today is we have a single repository with a single host. This is non-optimal for several reasons. There are different needs out there if we look at downstream consumers and/or enterprise users. They may want to have a restricted or supplemental repository. I may want to make available to my users an interface that shows only non-proprietary extensions, plus non copyleft templates plus my own proprietary house templates. Someone else might want to restrict things differently. Look at analogous things with Ubuntu component repositories, with the ability to disable or enable proprietary drivers and/or non-supported components. In a new design we could start up front with a specification for a data model for an extension, something expressed in simple XML, with a query/fetch interface as a RESTful service. This would allow multiple repositories to look and behave identically from the data perspective. That then allows websites that aggregate such repository data, as well as in-app browsers for extensions and templates. Then you can imagine AOO allowing a user or admin to enable any from a list of several extension repositories to work with. The other thing this approach does is separate the extension metadata from the actual licensed extension. If we wanted to have a canonical repository of registered extensions, but without actually hosting or storing the extensions, then that should be OK. We're hosting URL's to resources. We're not distributing code. (There might be some hybrid way of doing this as well, by using SourceForge or similar for the underlying hosting, but then with tags or a common extension.xml in the root of each repository, then publishing data that we create our catalog from) > (Happy to do the migration too if that’s needed) > > Gav...
smime.p7s
Description: S/MIME cryptographic signature
