Motivation

The current Ubuntu official packages update policy (described here) is limited to critical bug fixes, meaning after each release there will be no regular bug fixes or improvement updates. This a good practice for stability purposes specially if you are planning to do an enterprise level support but it also means that until the next release you will not be able to get the latest and greatest software versions for your system.
Experienced users and developers will be able to compile and install from the source but unskilled users which would like to try the latest versions will be complaining about how hard it is to compile software packages, specially those which depend on several development libraries.
This policy is also a limitation for the emerging applications which will not be available on the official repositories and consequently not getting the proper recognition, something that they can get by being easily available to the end users.

The Project

To overcome the described limitations a new project must be setup to make the latest versions of software available for the current *already released and supported* Ubuntu versions.
Please note that this is not an attempt to duplicate the effort from the ubuntu backports project. Backports do seek the same purpose however they are driven by the packages which have been approved and will be included on the newer *to be released* distribution version and not by the generally available version of the software as planned for the GetDeb project.

Exceptions

Newer packages will not include core libraries upgrades that will be incompatible with the official Ubuntu main/universe/multiverse application versions. If an application can not be upgraded because it depends on libraries/tools which cannot coexist with the current distribution version a special notice should be added to inform the users and the development team that the upgrade is not applicable.

Packages Organization

The software packages should be organized into sections (http://packages.ubuntu.com should be used as an example). The front page should display recently added/updated packages (freshmeat style).

Adding Packages

The packages will be added based on the voluntary work of the GetDeb packaging team, a package request option should be added and the users should be able to subscribe packaging requests, this would allow to track package demands and inform the users when the package gets available.

Packaging

Redundant effort should be avoided by checking if debian packaging build files are already available from Debian based sources, when not available debian package build files mus be created, creating packages using checkinstall should be avoided once they do not provide proper dependency checking.
Note: The GetDeb team may not follow the Debian/Ubuntu packagning guidelines meaning you should not expect the same level of quality control as you get from those. On the other hand you will be able to get usefull packages that will hardly get into Debian/Ubuntu due to policy constraints.

Availability

The packages will be available using FTP/HTTP download links, with Dapper it is now possible to install the packages by just double clicking the links, that will be simple enough for every user. An APT repository could be setup but it should be clear that it could automatically upgrade the entire system to unsupported application versions.

Training and recruiting

Packaging instructions and guidelines must be provided in order to allow new developers to get into the project and participate on the GetDeb packaging team as soon they get skilled.