Some suggestions:
* db abstraction layer based on xotcl: under some conditions and compromises, this would eliminate the need for supporting two different versions of the packages. it would also allow partitioning of data based on a given root of hierarchy (e.g. a class or a community). furthermore, a semantically-rich RAD tool on top of that.
* pageroot addition to site nodes: Enables the creation of a package with a variety of interfaces. For example, the blogger application would have three possible mount points (www-pvt, www-shared, www-global for private blog management, its shared part, and the aggregator).
* javascript-enhanced form and template builder: type validations and mandatory form element checks do not need to refresh the page
* support ajax calls in a structured way (an enhancement of the previous bullet point): for example, a way to represent the following: "on select of a country, populate the city element via the ajax call populateCityFromCountry"
* simplicity in the distributed packages but also the ability to subclass for complex customer scenarios.
* learn from gentoo (its portage system): openacs-core, openacs-lrn, openacs-wrk in the same way that gentoo has gentoo-sources, gentoo-hardened, gentoo-etc. USE flags. also, I second the need for subcategorization of the packages, e.g. infrastructure, kernel, app (or even dev-db, net-mail, app-forums). NOTE: each of these projects have their own teams with absolute control over what goes in or out.
* pageflows, workflows and lifecycles integration: a petrinets-based workflow package with integrated lifecycles support(workflow example: article publication workflow {assign --> author, author --> submit, submit --> approve_or_reject, approve_or_reject --(reject)--> [re-]author, approve_or_reject --(approve)--> publish) lifecycle example: the different states that an article goes through during its lifetime: draft, submitted, rejected, approved, live, archived). integrate with the db abstraction layer. lifecycles are basically a finite state machine (same for pageflows)
* marketplace section: let developers find companies and companies find developers. ditto for customers. let companies point to their showcases (online demos if possible). let developers state the required funding for developing a feature/subproject and let institutions and companies sponsor these features collective in as much as possible a transparent way.
* IMHO, use TIPs only when it's not possible to reach consensus via the forums.
