* Web Integration, possibly via [=ObjM2=] based [=WebObjects=] clone with coroutines replacing pthreads.

* Establishment a charitable non-profit organisation in Switzerland.

* A summary of difference between classic and revised Modula-2.

* A Style Guide.

* Project Wiki

* Web Integration, possibly via [=ObjM2=] based [=WebObjects=] clone.

* Web Integration, possibly via ObjM2 based WebObjects clone.

* Compiler back-ends targeting JVM and CLR.

* University courseware for introductory and advanced course in software engineering using Modula-2.

!!! Deliverables

* Compiler back-ends targeting JVM and CLR.

First, to offer a solution to the problem of unsafe and unreliable software through the design, implementation and provision of a safe and literate software development environment, free of charge, along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in software production.

Our mission is to make information technology safe and reliable by providing the design and implementation of a safe and literate software development environment free of charge along with associated training material to re-introduce, promote and apply sound engineering principles and best practises in the realm of software development in particular and information technology in general.

Our vision is that of a future where we will be able to go online without concern that we might become victims of sabotage or theft; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, professionals who do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost.

Our vision is that of a future where we will be able to go online without concern that we might become victims of sabotage or theft; a future where software controlled systems and devices are generally safe and reliable; a future where software developers will be true software engineers as they follow sound engineering principles and best practises in the manner today's electrical, mechanical and civil engineers do, where they do not exhibit the self-importance of "because we can" and the shortsightedness of "we fix it later", but the restraint and responsibility of serving safety and reliability first and foremost.

!!!Design Goals
* '''Revision''' of the language in the general context of today’s programming requirements.
* Following the Einsteinian '''simplicity''' principle ''“as simple as possible, not any simpler.”''
* Suitability as a '''safe''' alternative to C in systems implementation and systems programming.
* '''Clarity''' and '''maintainability''' of source code, specifically for readers other than the author.
* '''Orthogonality''' of syntax where possible, but not at the expense of simplicity and clarity.
* Non-interference of backwards compatibility concerns with any of the above principles.

!!!Feature Omission Guidelines
In the context of modern programming practise, if we found the omission of a feature to be reasonable and justified then we considered its removal. Conversely, if we found its omission to to be unreasonable and unjustified then we rejected its removal. We aimed to avoid oversimplification.

!!!Feature Addition Guidelines
We considered a new feature for adoption if a clear need could be demonstrated and if we found it to be reasonable and consistent with the overall design philosophy. We put a particular emphasis on suitability for systems implementation and systems programming as well as interfacing to C. We aimed for the ability to replace C as a systems implementation language.

When considering the addition of a feature, we looked at in the context of the weight of the entirety of features, not in isolation. We observed an imaginary baggage allowance, whereby items had to be removed to make space for others to be added. Our aim was to avoid feature creep.

!!!Backwards Compatibility Guidelines
If a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and consequently we removed it without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features.

* Compliance with the Einsteinian '''simplicity''' principle ''“as simple as possible, not any simpler.”''

In the context of modern programming practise, if the omission of a feature is found to be reasonable and justified it should be considered, if its omission is found to be unreasonable and unjustified it should be rejected. Oversimplification is to be avoided.

A new feature may be considered for adoption if a clear need can be demonstrated and if it is found to be reasonable and consistent with the minimalist design philosophy. Particular emphasis should be on suitability for systems implementation and systems programming as well as interfacing to C.

When considering the addition of a feature, it must be looked at in the context of the weight of the entirety of features, not in isolation. An imaginary baggage allowance should be observed, items may have to be removed to make space for others to be added. Feature creep is to be avoided.

If a certain practise is outdated, such as the use of octal numerals, then a feature that has no other use than to support that practise can no longer be justified and it must be removed without any regard for backwards compatibility of source code. Instead, a source to source translator tool should be seen as a suitable solution to backwards compatibility issues that arise from removal of outdated features.