I believe mixing game assets is not allowed by Bethesda, so it would need to remain a separate project from OpenMW.

Does not apply to OpenMW as OpenMW doesn't have any Bethesda IP in it. Only end users of Bethesda's games are obligated to follow their game's EULA , which they are doing anyway by playing either Morrowind, Oblivion, Skyrim or whatever at a time in which case they are not mixing assets anyway.

Bethesda's issue was with people porting assets and mixing them up in mods (back porting skyrim assets to oblivion for example). I don't agree with it, but that is their thing. Whatever, no impact on OpenMW.

Take for example if OpenMW supports NIF version up to Skyrim (we already kinda do by the way), that opens up a world of difference in terms of asset creation for people using OpenMW-CS and Blender. All of which has absolutely NOTHING to do with Bethesda, so why tell people that it shouldn't be done? Creating new games for OpenMW shouldn't be limited by the file format they use.

Please stop making stuff up and then telling people what they should or shouldn't be doing. You're not helping.

Take for example if OpenMW supports NIF version up to Skyrim (we already kinda do by the way), that opens up a world of difference in terms of asset creation for people using OpenMW-CS and Blender. All of which has absolutely NOTHING to do with Bethesda, so why tell people that it shouldn't be done?

Moreover, Bethesda does not own the NIF format. NIF was developed by NetImmerse (NetImmerse Format, NIF), now known as Gamebryo, and Bethesda only licensed the tools to make and use them for TES. The TES games each used a different version of the tools, hence the different games using different NIF versions, but the format's not exclusive to TES/Bethesda. NifSkope, for example, has long supported NIFs not only from the latest three TES games, but many other versions of the format used by non-TES games as well.

Let's think very carefully about this. In a completely different domain, you have had countless attempts to replace Javascript within browser, because everyone seems to agree that it is lacking, and so there were many projects like Dart that attempted to replace it but languished. There is only one exception. Typescript had a singular focus, aiming to be a strict superset of javascript, and to compile back down into javascript. Every competing project with another mission has failed, even if it had theoretical benefits in terms of purity and starting from a clean slate.

Using that analogy, OpenMW is like WebAssembly, which is intended to be a complete replacement for JavaScript (and its high-performance superset asm.js). For the time being, a polyfill exists that allows WebAssembly to be translated into JavaScript so that browsers that don't natively support it can run it. But over time, all browsers will support WebAssembly, meaning that compatibility with JavaScript will no longer be necessary. I think that this is pretty likely to happen, given that Mozilla, Microsoft, Google, and Apple are all working together to make this happen (and Wikipedia says that 57% of web browsers used globally currently support it). It's the strength of the leadership.

In the same way, OpenMW currently has backwards compatibility with vanilla Morrowind (in fact, you can take an OpenMW-CS addon and rename it from .omwaddon to .esp and it will work in vanilla Morrowind). But in order to move forward, we'll have to break away at some point. Vanilla Morrowind will never allow me to make an addon that allows me to add a new skill, but OpenMW could. Just like with WebAssembly, I think that the strength of OpenMW is in its leadership, and the support of many prominent members of the modding community (e.g. Tamriel Rebuilt, Morrowind Rebirth, etc). That has what has made it such a successful project.

Heck, the analogy doesn't stop there. WebAssembly allows compilation from multiple languages, like C, C++, and Rust. The TES3MP fork of OpenMW allows writing Lua scripts to affect the Morrowind game world, instead of just the vanilla scripting engine. I think it's pretty likely that post-1.0 OpenMW will allow this as well.

I agree that a vision and goals for post-1.0 OpenMW is desired, but I disagree that backwards compatibility with vanilla Morrowind should be one of those goals.

In the "let's be nice to each other" arrangement we have with Bethesda (which strictly speaking, we could probably deviate from, but practically speaking, they can afford more lawyers than us, so we shouldn't) we're not supposed to promote OpenMW features which show capabilities they don't like if it uses their assets. For example, if OpenMW was working on Android again, we could show it running the example suite in a release video, but once we show Morrowind running on a phone, Bethesda will be angry. Similarly, if we add support for other Nif formats, we can't show a video or screenshot with Parthunax in the middle of Vivec. We can get away with it being possible for a user to put him there, though.

The arrangement was purely for Morrowind on Android. It has nothing to do with showing features off, which we can do... and is encouraged, so long as it doesn't use Morrowind assets in the Android footage. Hence the example-suite, we can demo that to our heart's content on our own front page running on Android. Which we SHOULD ALREADY BE DOING. Sadly no one seems to want to further sandstranger's work.

I want to thank you, nwah, for this thread, because I think it's asking legitimate and important questions. I don't agree with retaining compatibility with Morrowind in the same way, but that has been said already.

Now, currently this thread seems to be for comparing visions for post 1.0 and that's certainly an interesting thing to do. But I don't know enough about who makes which decisions regarding the openMW project to know whether that makes sense right now. If anyone knows about the inner workings, or if you're really interested in proceedings, click the spoiler, otherwise skip it.

Because, if there's no protocol in place, then whoever has admin rights to the git repo is the factual decider over what becomes part of openMW and what doesn't. Sure, everybody can fork it, but most people will probably only look at the original repo.
So my question is: Is there already a protocol/some guidelines or sth like that in place about post-1.0-merging? Because right now, I guess, the decision making process simple enough that no such protocol is needed (a. Does it do sth that vanilla MW has but openMW doesn't yet have? b. Is the code quality acceptable? -> If 1 and 2 are true, merge).

It's very easy to over-formalise any process or group, but it can also streamline things a lot if some basics are there. And it would just be about putting into words what everybody feels is the most natural way to do things.

For example: I think, it makes a lot of sense if the person who actually has to do the work in the end, i.e. deciding what gets merged and maybe even having to make adjustments, has the final say. Because nobody wants to do other people's work. But to support that person, some guidelines as to what the original authors and contributors had in mind, or what the community wants, or what users seem to like, might help the decision making process.

Because I like the idea of this thread, but I think it could be more specific, here's my suggestion:

Then, if people object to an item, or want to change or specify it, or want to suggest an alternative, we initiate a vote on said item, either with a simple yes or no, or with the options provided.

And if you find that a good idea, we can do that in a separate thread, in which the first post contains the items currently favored by the community. Which is then the non-binding community guideline for post 1.0 openMW.

Thoughts? Good idea/bad idea? Crazy over the top? Tell me. Oh, and if anyone tells me how to initiate votes here, I'd also volunteer to do what I described above.

I have most of the near/medium post 1.0 design worked out already except for the graphics part for which I will ask scrawl for help once we are getting there (still need to write down most of it). The idea is to post all that stuff in the forum, once we reach 1.0 (or in the RC phase) and then we can discuss it, make adjustments, add things and so on.

As I said, it should be non-binding, because the final decision should and will always be up to the people doing the work. The question is how we organise the input from non-developers and ones who aren't you and scrawl.
I am eternally grateful for all you've done and are still doing.
I only think others might have good ideas - or turn other people's half-baked ideas into good ones - too.

Edit: Also, as written above, the vote would only come into play for contested items. I've actually had a lot of good experience with this model, in a similarly open group. So I disagree with it never ending well. It's user-sensitive

The question is how we organise the input from non-developers and ones who aren't you and scrawl.

That's what the Feature Request and Suggestions forum is for. We largely ignore it right now, because 1.0 is more or less fixed. Post 1.0 I expect that we will harvest this forum for ideas periodically.

Fine by me for how things are right now.
But there are several cases for which I think there are better options. One such case is, if either you or scrawl, or both of you quit at some point. I hope that doesn't happen, but I've seen it before, especially at the end of a project (phase). Another case is if there is a significant number of new devs joining after 1.0.

And for these cases, we could comb through the forum already, collect old and new ideas in a dedicated post-1.0 thread, and craft a more-or-less unified vision from it, which can be used as inspiration for other devs, too.

Also, I'd be the last one to object to heavy contribution for said vision from you and scrawl. But it would be nice if that vision would be public, and I think that's part of the reason why this thread was created in the first place.