With Ease3 we would like to regain a dialogue among all, agree together a clear roadmap, build realiable and stable releases, actract again professionals, have companies which pay for extensions or core changes.

In the architecture of TYPO3 up to version 4.x we see a great analytical effort, a construction which has been built over years following a coherent plan, and we'd love to continue in that direction.

At the same time, we'd like to improve communications between Ease3 core developers (whoever they are, us or others) and general community.

Coherent and stable design of API, interfaces, requirements.

We'd love to avoid that an upgrade of CMS or the installation of an extension is aborted due to PHP problems, CMS version, change of interface.

So we plan to keep stable as long as possible Ease3 CMS.

This means that new API or changed API, core function, extension, PHP requirements will remain stable whenever possible, and will be compatible with past versions.

We welcome new versions of PHP or Ease3 or extensions, and so we welcome new functions and new possibilities. Of course there will be new API, or changed API, but we'd love each new extension or each new change of code will care about keeping compatibility at the most.

We'll be very restrictive on using new PHP functions which will break compatibility.

There are a lot of areas where a lot can be done.

Safer login management, groups profiling, users profiling, for example.

And a different structure in CMS, keeping all CMS code and extensions not accessible to public WEB access (except for public resources).

Everything must work fine, despite changing of php or changing of CMS releases or changing of extensions.

Logging can be improved a lot and integrated with extensions. We have developed a specific library for extended logging, and we are using it deeply in our projects, but we have to evaluate if to port it inside (or side to side) to Ease3.

In our projects we have semplified flexform integration, development of standard extensions, scheduler tasks, usage of project libraries, and we'd like to share all that with other developers.

Some features have already been integrated, other will be later.

One big step will be a drastic improvement of Kickstarter, which could semplify a lot design and coding of extensions.

We see another big area of improvement in SQL management: actually only one constraint is permitted for each table, no unsigned integers are allowed (and so contraints on uid cannot be made), null values are not recognized, and so on.