Join efforts with the Active Oberon team at ETHZ.

http://www.ocp.inf.ethz.ch/wiki/

There are still some students and external guys keeping the ports going.

http://www.ocp.inf.ethz.ch/forum/index.php/board,4.0.html

Nowadays, I think Oberon spirit will live in Rust, D, Go, C#. :)

I don't see much if any of Oberon's spirit in any those languages. Maybe Go, though I don't like it much. Part of the point of Oberon was the minimalism - each of Wirth's language got simpler and smaller, and the system aimed to remain tiny too.

In terms of the language, the Oberon 2 language report is 17 pages of which 1.5 pages is the full EBNF for the grammar.

Then again, looking at the new stuff from the people keeping Oberon alive, it seems much less interesting to me as well.

The spirit of using strong typed safe languages for system level programming instead of unsafe languages like C and C++.

I did like Oberon a lot, as a GC enabled safe systems programming language with module support, and the ideas of Native Oberon exploring Smalltalk dynamism in a static compiled language.

As for Wirth's minimalism, specially the latest Oberon-07, I don't like it that much.

Has any of Oberon's "spirit children" been used for a full fledged OS yet?

Just kernel level, or partial state projects that were abandoned.

D - Xomb - http://wiki.xomb.org/index.php?title=Main_Page

Go - TinyGo - http://code.google.com/p/tinygo/

C# - Singularity - http://singularity.codeplex.com/, Cosmos - http://cosmos.codeplex.com/

The main problem is lack of support, it is a very big effort to create an OS and it is very easy to turn attention to other stuff.

Linux and BSD distributions wouldn't have reached the state they enjoy nowadays, without the help of the existing UNIX toolset and investment of companies interested in seeing the projects succeed.

Responding to pjmlp, a cool project I saw recently that's related to the ones you mentioned is Unikernels [1]. They noticed that a challenge faced by a lot of those projects is hardware support--each OS has to ship with a huge set of drivers to be widely usable. They sidestep this by targeting a VM, which exposes a single hardware interface no matter what it's running on.

[1]: http://anil.recoil.org/papers/2013-asplos-mirage.pdf

Some researches from the Singularity team moved on for the same type of work for Windows.

http://research.microsoft.com/en-us/projects/drawbridge/