While these are called "Oberon", judging from the screenshots (i haven't watched the videos), they seem to be way beyond the minimalistic nature of the Oberon system shown in Project Oberon.
I think the emulator linked at the bottom left side is a better way to check out Oberon in action as you can easily (well, after you figure out how things get compiled, etc :-P) see it in practice and how a few individually simple (if not outright primitive) things can be combined to create something nice. For example i always found it amusing that the "menu bar" in each window is really just a regular text area and the commands shown are really methods that are called when you (IIRC) middle click them, like any other text in a window (so the main "GUI" for a program can really by just a text file with methods to click on - and of course since it is editable you can simply customize the GUI by editing the text file).
They are Oberon, the system that was described on the first edition of Project Oberon was the version 1.
ETHZ researchers and Niklaus Wirth then iterated further on the Oberon (the OS) and Oberon (the language).
The definitive Oberon (the OS) version that still uses the plain Oberon (the language) from original project was System 3, which is what those videos relate to.
In Active Oberon used to write AOS (BlueBottle OS), you can still relauch System 3 as a nested OS.
I consider Active Oberon and AOS to be forks, and I think Wirth does, also. I believe that he feels that Project Oberon is his final word on the subject.
Wirth created Oberon-7 largely by removing features[0]:
Revised Oberon (Oberon-07) is a revision of the original language Oberon as defined in 1988/1990. It is accepted by the compiler recently completed for the ARM processor. Most changes in the language might easily be called features of a dialect. However, there are a few that merit a stronger distinction, because they should be considered as permanent, and as corrections of unsatisfactory properties of the original Oberon. These are the elimination of the loop statement, function result specification, array assignments, constant parameters, and read- only import of variables. All changes were made in the interest of regularity, simplicity, completeness, and well-structuredness.
See also [3] for confirmation that Oberon-7 is the language of Project Oberon.
I'd recommend reading the papers on Wirth's personal site [2].
Project Oberon cannot be his final word, given that it is only the first version, later upgraded up to System 3 version.
It is hard to consider them forks, when they originated on the same department and he also collaborated in some form.
Component Pascal and Zonnon, those are proper forks.
While I admire Wirth's work, his goal to pursue a minimalist Oberon with Oberon-07 is not so interesting to me.
My pocket phone is more powerful than any Xerox workstation, why should we keep searching for such minimalist endeavours, instead of the rich development experience provided by them.
Your pocket phone is more powerful than any Xerox workstation, but you and I are less powerful than Wirth, so if we want systems we can understand and restructure at will, they probably need to be simpler than what Wirth could handle, not more complex.
Yes they are Oberon too but my point is that they've evolved and added a ton of stuff that go further than the minimalistic nature of the linked site. The "Project Oberon" in the site doesn't even have overlapping windows or color for example.
The point of the linked project isn't to evaluate what the most advanced version of Oberon is but to show a minimalistic system built from the ground up in a way that can be entirely understood by a single person. It is mentioned at the top of the page.
I think the emulator linked at the bottom left side is a better way to check out Oberon in action as you can easily (well, after you figure out how things get compiled, etc :-P) see it in practice and how a few individually simple (if not outright primitive) things can be combined to create something nice. For example i always found it amusing that the "menu bar" in each window is really just a regular text area and the commands shown are really methods that are called when you (IIRC) middle click them, like any other text in a window (so the main "GUI" for a program can really by just a text file with methods to click on - and of course since it is editable you can simply customize the GUI by editing the text file).