ESC/Criteria for bundling extensions

Why Extensions ?

(draft for proposal for ESC meeting 2009/03/09)

OpenOffice.org offers a language independent application programming interface (API) which allows to program the office in different programming languages (e.g. C++, Java, Python, CLI, StarBasic, JavaScript, OLE). It allows to use OpenOffice.org as service provider in other applications, extend it with new functionality or simply customize and control OpenOffice.org.

Users often demand the integration of office productivity into existing work flows and applications. They also often require additional functionality or special customizations of the existing features. Providing the possibility to customize or control the Office is the main objective of Extensions.

Adding or removing functionality is easily possible with extensions, this can be done at run time. Beside this there are also some interesting side effects by doing feature implementations with Extensions:

Customize OpenOffice: Customize the OpenOffice.org product by defining the feature set and deliver this to your customers.

Independent release and translation schedule of extensions: extension not bundled with OpenOffice.org can be released independent from that schedule. An extension can be released more often or just earlier via the extension repository.

Experimental Code: The release of code not yet production ready is possible via the extension repository.

Easier development of extensions: Building extensions is a lot easier than implementation of new functionality in the core OpenOffice.org. The build requirements for building a full featured OpenOffice build are much higher.

Beside the main objectives described above there are some other objectives and concerns:

• Architectural View: Leverage the implementation of functionality with extensions, make this technology broadly known, used and available. This can be achieved by keeping the core product as small as possible, move as much functionality the the extensions repository.
• Engineering View: keep the OpenOffice.org core product as small as possible to avoid compiling unnecessary stuff and keep build times fast. Weigh the effort and code size from an extension implementation against the effort inside the core. Consider potential duplication of code and functionality.Don't implement extensions that will be ABI-dependant.
  Don't circumvent URE-only component limitations by statically linking office libraries.
• Performance: Extensions can have significant overhead compared to core implementations, since they are limited to URE/API
• User Experience View: keep OpenOffice.org User Interface consistent and keep the work flow easy. Talk:ESC/Criteria_for_bundling_extensions
• Marketing View: “put as much mature functionality in as few bits as possible”. vs “promote the extensions repository as a market place where OOo users also can get external 3^rd party functionality”.

One of the main advantages is that for a deployment of OpenOffice.org it can be decided which functionality actually get installed, but what should the vanilla OpenOffice.org distribution look like ?

It's quite obvious, which kind of extensions should not be bundled with the vanilla distribution of OOO:

• not fully translated extensions
• not fully documented extensions
• extensions, which are not ready yet.
• Not fully QA'd extensions
• extensions, which are not a11y compliant
• extensions not consistent with the OOo UI

This leads to the minimum requirements, that extensions, which are questionable for bundling must at least fulfil these requirements:

• translated (TODO: for which or how many languages ??)
• documented, online help available
• the extension must be Does the extension need QA for every OOo release anyway, thus inflating the QA matrix when not included?QAd, Feature must be complete and without serious bugs
• consistent with the UI of the core product and other bundled extensions
• is not considered as core functionality at the same time
• a11y compliant

Since there can be many extensions that fulfil these criteria, they are some other criteria

• the installation set of the core product should stay reasonable small (TODO: what is reasonable small?, should fit onto one CD (including one language pack, SDK), should be downloadable in less one hour for 80% of the online User, e.g. 1MBit DSL limits this to 480 MB, that also fit onto one CD )
• if the bundling of the extension is expected to keep the product competitive or help to increase the market share.
• extension repository needs to stay attractive to get new extension developer involved and to get constantly new extensions. The extension repository as a market place is also important.
• the source code of the extension must be available in the OOo source code repository → extensions must be licensed under the OpenOffice.org license. There will be a defined exception for non code extensions, e.g. dictionaries or documents/templates which may come under another OSI approved OpenSource license.

issues:

• should bundled extensions keep listed in the extension manager ? Or is a special view more convenient ?
• Should there be an limit of the amount of bundled extensions ?