General Question What is the main reason the Orbiter simulator is freeware?

[marvin300]

What do you think are the benefits of having Orbiter licensed as a freeware and not with an open source license (like Orbiter License :lol?

I do respect Martin's freedom of choice in this matter; I would like to hear your opinion on why Orbiter is closed-source application.

If you are unfamiliar with Open movement, please do read

• https://en.wikipedia.org/wiki/Open_source
• https://en.wikipedia.org/wiki/Open-source_software
• https://en.wikipedia.org/wiki/Open_science

BTW: similar question was asked 6 year ago in http://www.orbiter-forum.com/showthread.php?t=8091

 

[kuddel]

...I do respect Martin's freedom of choice in this matte

That should be reasonig enough, shouldn't it? It was/is his choice!
What kind of freedom is it if you don't have a choice?

 

[boogabooga]

I suspect the reason is that it would be too easy to remove proper attribution and release Orbiter as payware under some disguise.

 

[RisingFury]

I like that it's closed source.

We're a very small community and opening the source would create 3 or 4 different Orbiter branches. Syncing addons between them would be a nightmare.

 

[N_Molson]

Because the wants it that way.

would create 3 or 4 different Orbiter branches

Which 3 or 4 similar addons on each branch, each having 3 or 4 sub-branches... :rofl: :beathead: :suicide:

 

[Face]

I like that it's closed source.

We're a very small community and opening the source would create 3 or 4 different Orbiter branches. Syncing addons between them would be a nightmare.

Agreed.

[rant]
For me the best example is the OVP compatibility mind-set that quickly developed after the concept was released: now addons need to be compatible with a specific graphics client, not the client compatible with Orbiter addons.
And don't get me wrong: this is not because client developers forced it so or even wanted it that way - quite the opposite. Client developers (and Martin as API developer) worked hard to prevent it. Still it happens because the user experience leant that way.
And now you have a situation where people criticize "missing <OVP client> compatibility" in Orbiter addons that work perfectly fine in the inline engine.
[/rant]

Judging by that I shudder a bit thinking about a situation where there are various Orbiter engines.

just my :2cents:

 

[Matias Saibene]

In this case, I guess Orbiter could suffer syndrome "versions of Linux" (Linux kernels).
Can you imagine as would be Orbiter version 2.3.4.7.8-1.1x2.3.H.etc?:uhh:

 

[RisingFury]

Agreed.

[rant]
For me the best example is the OVP compatibility mind-set that quickly developed after the concept was released: now addons need to be compatible with a specific graphics client, not the client compatible with Orbiter addons.
And don't get me wrong: this is not because client developers forced it so or even wanted it that way - quite the opposite. Client developers (and Martin as API developer) worked hard to prevent it. Still it happens because the user experience leaned that way.
And now you have a situation where people criticize "missing <OVP client> compatibility" in Orbiter addons that work perfectly fine in the inline engine.
[/rant]

Judging by that I shudder a bit thinking about a situation where there are various Orbiter engines.

just my :2cents:

No, you're absolutely right. If Orbiter's core was open sourced, instead of graphics clients, we'd get different orbiter builds, all with their own inline graphics clients.

Orbiter would turn into Linux.

 

[Urwumpe]

BTW: similar question was asked 6 year ago in http://www.orbiter-forum.com/showthread.php?t=8091

This question is asked so often, we should open-source the question, not the simulation.

---------- Post added at 08:51 AM ---------- Previous post was at 08:21 AM ----------

In this case, I guess Orbiter could suffer syndrome "versions of Linux" (Linux kernels).
Can you imagine as would be Orbiter version 2.3.4.7.8-1.1x2.3.H.etc?:uhh:

Actually, such versions are not a sign of bad management or overmanagement... there is a common standard around called "semantic versioning" that gives every number in the version string a specific function.

You could have it as simple as just 2.3.4 ... and then, you could add more context.

For example, the beta version would be

2.3.4-beta

Or you create a special x86_64 build:

2.3.4-beta+x86_64

Or

2.3.4-beta.2+x86_64.openmp.directx12

which would mean:

Beta 2 of major version 2, minor version 2.3 and patch release 4, with x86_64, OpenMP and DirectX 12 support as optional features included into the release artefact.

http://semver.org/

 

[jedidia]

This question is asked so often, we should open-source the question, not the simulation.

Hmmm... maybe a sticky with an official statement might be a solution to that?

 

[Urwumpe]

Hmmm... maybe a sticky with an official statement might be a solution to that?

We have a FAQ for that... but that question never made it into it, it seems.

 

[Abdullah]

The question can be answered by looking at the history of opensource software.
From my own personal experience, I am at the moment part of the community of Minetest, a very famous, opensource and non-java lookalike of the famous Minecraft. AND, there is a HUGE amount of chaos in there!!! Arguments between devs that have led to certain features being not implemented, and even REMOVED from it!!! And there are TONS of forks of it! And I am at the moment a part of the small community of one of them, known as Voxelands. It's much more awesome than Minetest. And I have a copy of another fork, called Freeminer. And it is also better than Minetest itself.

Talking about forks, we come to the second point. Many times, forks of opensource software tend to raise above the original one, and draw people away from it, and, eventually, in the immediate worst case scenario, killing it altogether. Personally, I am at the moment contributing to the original Minetest with mods, but mostly because I can. If I am able to contribute to Voxelands, there is a high possibility I might leave Minetest altogether, due to it's current direction as opposed to VL.

---------- Post added at 04:12 PM ---------- Previous post was at 04:09 PM ----------

That said, I must note that opensource software live longer than closed source.

 

[Urwumpe]

The misunderstanding is, that Open-Source is open for amateurs, but the opposite is the case: OSS requires stricter standards and more professionalism than closed source software.

If you plan to do OSS you need a core team of highly motivated professional developers who are also expert enough in terms of software architecture to oversee one module or layer as Tiger Team. You need processes to manage changes.

And protect your sources against uncontrolled modification.

I can understand any sensible developer who decides against OSS. Its harder work. But often the most fair and easy way to bring a group of specialists together.

 

[Abdullah]

You're right Urwumpe. As far as I know, Minetest, despite being open source, requires random people who want to contribute to submit github commits. ONLY trusted developers can straightaway modify content.

 

[Urwumpe]

You're right Urwumpe. As far as I know, Minetest, despite being open source, requires random people who want to contribute to submit github commits. ONLY trusted developers can straightaway modify content.

Yes, and that random is the problem. You don't want any random software, after all. You have goals. You want to be flexible, not random. flexible does not mean, you take any commit, but if somebody has some promising contribution to make, you work properly to integrate it, by adding this new code into the standard workflow to include it.

That is also the big annoying trap in Open Source: In the beginning, when you define most of your processes and habits, its easy to let everybody contribute, because the software is small and simple. When it grows bigger and more standards are worth to be kept, you badly need such processes. In the worst case, you need to kick people out of the repository and cause bad blood in the community.

 

[Abdullah]

This "random" problem would be true more so in the case of an opensource Orbiter. If Orbiter DID go opensource AND was not regulated, the complicated and delicate mathematics used to calculate performance of spacecraft realistically and accurately could easily get messed up by ignorant/malicious/some other sort of devs. And pretty soon Orbiter would become unplayable as a realistic spaceflight simulator and more like become a vomit stimulator :rofl:

 

[meson800]

This "random" problem would be true more so in the case of an opensource Orbiter. If Orbiter DID go opensource AND was not regulated, the complicated and delicate mathematics used to calculate performance of spacecraft realistically and accurately could easily get messed up by ignorant/malicious/some other sort of devs. And pretty soon Orbiter would become unplayable as a realistic spaceflight simulator and more like become a vomit stimulator

To be fair to open source, I have never seen an "unregulated" open source project. Sure, everyone can pull request/submit a patch, but someone more involved with the project always pulls it/applies the patch. In that case, it is relatively hard to accidentally/maliciously change core behavior.

So, there would be a way to open source Orbiter without it dissolving into chaos (at least not the chaos described above).

However, I am not suggesting that this would be a good idea.

too easy to remove proper attribution and release Orbiter as payware under some disguise.

opening the source would create 3 or 4 different Orbiter branches.

Judging by that I shudder a bit thinking about a situation where there are various Orbiter engines.

:theysaid: