Discussion "Orbiter Council" to guide open-source development

DarkWanderer

Active member
Orbiter Contributor
Donator
Joined
Apr 27, 2008
Messages
213
Reaction score
80
Points
43
Location
Moscow
Greetings

Given that @martins - most understandably - may not have time to dedicate to constant development of Orbiter, I think it might be worth discussing whether and how the community itself may help the project to progress. I think everyone would agree that having a single person be a gate for all the pull requests is not an optimal usage of said person's time - as well as potential blocker for many new features

There are successful games which follow this model - FalconBMS, OpenRA - so there is precedent. And with a community as passionate as Orbiter's, I think this may work well too

Proposal​

  • Nominate 5-7 people to form a "Council" which will take control of Orbiter Open Source repo - PRs, issues, etc.
  • Use GitHub repository "Project"/"Issues" feature as the means of management
  • Create a "Council" group in Orbiter repo with appropriate permissions (management of issues, projects, PRs etc) - to not give full admin access

Legal status​

Current Orbiter sources are published under MIT license. This means that at the very least, a derivative product can be created and published using "forked" source code. Of course, ideally we'd have original author's permission to use the original repository and all of the materials - which seems to have been the intention (given creation of a separate organisaiton on GitHub), but an explicit confirmation would of course ease things a lot

Suggested members​

A few names which are already known well enough in the community (and of course, if they agree to participate)
@dbeachy1
@Xyon
@DaveS
@jarmonik

Questions to discuss​

  • Cut the current state of 'master' branch into a separate "x86-release" branch, to facilitate "the last release™"
  • Merge the current WIP branches - d3d9 etc. - into 'master' and continue developing from there
  • Determine 2-3 most "painful" areas with the game currently and create tickets for them
  • See where that takes us...
 
Last edited:

OvalDreamX

Active member
Joined
Sep 16, 2019
Messages
61
Reaction score
100
Points
33
Location
Bariloche, Patagonia Argentina
It would also help recruiting and organizing contributors into teams, thus focussing efforts more efficiently and doing a better job on informing the community on progress better. Orbiter (or OpenOrbiter) would really benefit from this "orbital council" I think

(Messy english, ik)
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,879
Reaction score
1,537
Points
203
Location
Langendernbach
I think the idea isn't too bad, but I would recommend to use a really low WIP limit there, at least initially, to not overwhelm this body with user stories. Transparency is really important so make sure, that everything in this council happens at a regular pace (fixed timeboxes!) and it is easily visible for anybody inside and outside the council, what its duties are. Also, this council should include people supporting it with the boring bureaucracy, like writing protocols about meetings and decisions into the Wiki. It is annoyingly German maybe to demand this, but transparency and reliability are important values for any community building.

Also, I would ask the basic constitutional question: How will people be selected and replaced? How does the council decide? How will conflicts be resolved?

In case of software architecture decisions, I could recommend some "supreme court" like approach to decision making: Democracy, what has most votes/support will be done, but the concerns and recommendations of the opposition get into a "minority report". This kind of documenting alternatives as you go is really helpful, should a popular decision turn out to be the wrong one.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,002
Reaction score
1,634
Points
188
Website
github.com
So would this fork Orbiter or the council would joint Martin and run the official repo? :unsure:

As for roadmaps and such, I'll repeat what I posted in other threads: the x64 work should be in a branch, while the last x86 release is worked in the master. When the x86 gets released, merge the x64 to master and officially turn Orbiter into x64.
Major changes like that should also go in branches/PRs, to make sure they work well before merging to master, to avoid "polluting" the master with bugs. Minor work can go directly in the master. PRs should be merged to the appropriate branch, unlike what has been happening with "general" PRs being merged into the D3D9 branch instead of master. Not following this hinders the dissemination of that PR to the rest of the repo.

As for my "plans" for Orbiter, once I get SSV 1.0 out the door, I'm planning to dedicate sometime to Orbiter.
 

n72.75

Addon Developer
Addon Developer
Tutorial Publisher
Donator
Joined
Mar 21, 2008
Messages
2,295
Reaction score
846
Points
128
Location
Biddeford ME
Website
mwhume.space
Preferred Pronouns
he/him
I think this is a great idea. I would also caution against being quick to add new features. Steady incremental development is always better.

I do have a short list of (hopefully uncontroversial) features that I would like to implement/see implemented, which I am very reluctant to put out there without at least some legwork on my end. One of these, I have already started work on, but it is not done to the degree of robustness and quality that the rest of Orbiter is, so I won't even think about considering including it until it is. We're also a pretty well behaved forum so even if there were a flood of feature requests, I don't think it would be a terrible thing.

One other thing I would recommend is a good dialogue between and among developers/"council members" before someone starts a project. This is to a large degree how we have done NASSP development at least as long I have been involved. This will go a long way to improving team cohesiveness. There is already a discord channel; IRC is pretty good for stuff like this, even in 2022, as long as someone runs a logger.

Defining some type of contributing guideline would be a good thing to have.
 

Abloheet

Addon Developer
Addon Developer
Joined
Apr 18, 2009
Messages
198
Reaction score
16
Points
33
Location
Kolkata,West Bengal
The Orbital Development Council will be an important step forward in the story of the community becoming more involved in the development of the Orbiter Core itself.
I look forward to actively contributing whenever possible
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
985
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
I hope something comes out of this (y)

But think some thought should be given towards the actual needs of Orbiter users and addon developers (in the broadest terms, nor necessarily coders).
There's been a disconnect between some of the features being developed and what is actually used. Also, some thought must be given towards compatibility. This was disregarded between 2010 and 2016, and it almost killed the community. I fear that newer incompatible versions might be the end of it.

In more practical terms, I guess the vast majority of users are expecting to install a "windows download" and to use this forum for questions. They will be confused by GitHub.
So adopting a model similar to https://www.openra.net/download/ (website with large download button, is a must. In fact OpenRA seems like a good inspiration (especially because they have retro-compatibility in mind).

Just my 2 cents :)
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,358
Reaction score
513
Points
153
Location
Vienna
Retro-compatibility could get tricky once x64 is used: without some sort of IPC marshaler, I fear all old DLL addons will become incompatible, anyway. And I also think that newer incompatible versions might be the end of it.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,879
Reaction score
1,537
Points
203
Location
Langendernbach
So, no hard switch to x64.

But what about the alternatives? Could we evolve the Orbiter API in a way that makes a later switch to x64 easier?

What about a "Legacy add-on replacement" project, that exists independent of Orbiters core?
 

Face

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,358
Reaction score
513
Points
153
Location
Vienna
Yes, I think still keeping x86 in mind could be a good idea. Last time I checked, it was possible to compile the same code base for x86 and x64, so an OpenOrbiter project could offer both versions for those users wanting to run legacy content. Not sure if this will become a burden in the future, though.

With the replacement project, do you mean re-coding legacy addons like OS and SC5, given that the authors don't update it?
 

WolfAngriff

The NSEU (Never Satisfied End User)
Joined
Nov 9, 2013
Messages
133
Reaction score
89
Points
43
Location
Brest
Hello,

As Urwumpe said, from my very naive point of view, i think this council needs a Quality System Management, or kind of. A part of boring bureaucracy sould be needed at the beginning, as to avoid future complications. As i work in the industrial quality system, i know it's difficult to build. But it could give a "frame" (sorry for my english) in which things can go realy more easily. A suggestion : people involved in the creation of this "frame" should be out of the development and building of the project, as to preserve objectivity. I'm not speaking for myself. Even if i'd love to, I know i won't be able to be in the project for a long term. But i should perhaps be able to provide simple advices if needed. And it could give me a good oportunity to practice professional english.

All the best to all of you.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,879
Reaction score
1,537
Points
203
Location
Langendernbach
I think an automatic code checker that enforces style and standards should be enough to keep things mostly on track. I assume there is something like that for C++/Visual studio?

Lets look at something on CLI, that can be used regardless of the preferred IDE. So, for example:


This one should also work on any kind of windows development:

 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,879
Reaction score
1,537
Points
203
Location
Langendernbach
With the replacement project, do you mean re-coding legacy addons like OS and SC5, given that the authors don't update it?

I more looked at the end-user perspective there, I am not sure how much use newer frameworks would be regarding making older add-ons compatible.

I more thought about having two things:

A coding standard for such add-ons to reduce the complexity and the number of required dependencies.
And redoing older add-ons (ideally from 2006 or earlier) based on this standard, that won't be updated eventually.

All should aim at fixing or improving one such abandoned add-on per month, ideally with as little coding as possible. No VC, maybe Panel2D, if we can get a good framework there that permits a low-code approach. Maybe also include MFD add-ons.

Who wants a newer, greater, better, more shiny add-on there, should never fear competition from such a basic add-on - but it isn't the scope.

The product should be a set of scenarios and configuration files with only few modules.

For example, we had an aircraft.dll once. If somebody could produce a similar generic module, we could quickly port many of the old Kev33 add-ons back to Orbiter in such a replacement project.
 

WolfAngriff

The NSEU (Never Satisfied End User)
Joined
Nov 9, 2013
Messages
133
Reaction score
89
Points
43
Location
Brest
I think an automatic code checker that enforces style and standards should be enough to keep things mostly on track. I assume there is something like that for C++/Visual studio?
When i speak about Quality System Management, it's not only about what is good or wrong in the product. That part is more Quality checking. If it's automated, it's useful. But i'm speaking about organization. The Quality System has a wider range than "only" checking if things are OK or KO. Quality System's job is to care about what's "around" people working directly on the project, for example the quality of the organization itself (roles, tasks, reportings, communications...), as to anticipate what could disturb or complicate developers jobs. In industry, Quality checking depends on Production system. I won't go further in these explanations, it's boring and perhaps not useful at all. Shortly : it's a neutral (towards operators) support, with a strong end-user (client) orientation. I hope it's clear enough...
 

4throck

Enthusiast !
Joined
Jun 19, 2008
Messages
3,502
Reaction score
985
Points
153
Location
Lisbon
Website
orbiterspaceport.blogspot.com
Compatibility might be a discussion for later on, but here goes:

I'm assuming(*) that most users would consider 2010 as the baseline version.
As far as I can tell, 2010 to 2016 compatibility is currently limited by a single issue: text output to the HUD, causing a CTD.
Other problems (like landing points or flat bases) are solved, either using MFDs or D3D9, or are minor and won't prevent overall add-on functionality.
Personally, I have no need for a 64bits version that runs even fewer addons than the current one...

(* I'm just one guy guessing. It might be worth doing some kind of Census, to know what the community feels as important, and let that guide future development.)
 

Max-Q

99 40
Addon Developer
Joined
Jul 5, 2021
Messages
417
Reaction score
591
Points
108
Location
Cislunar Space
Website
www.orbithangar.com
Why the big push for 64 bit? 32 seems to be doing fine, especially given the performance increase with D3D9. To me, is seems a bit silly to knowingly break literally thousands of addons for… what?
 

WolfAngriff

The NSEU (Never Satisfied End User)
Joined
Nov 9, 2013
Messages
133
Reaction score
89
Points
43
Location
Brest
Personally, I have no need for a 64bits version that runs even fewer addons than the current one...
Yes. What has nearly killed Orbiter and it's community must be objectively analysed, from the user's point of view. And it doesn't come only from Orbiter only : other "simulators" have made damages too.
 

jedidia

shoemaker without legs
Addon Developer
Joined
Mar 19, 2008
Messages
10,304
Reaction score
1,501
Points
203
Location
between the planets
I hope it's clear enough...
I get the picture. Might be a bit early for such things, though...

To me, is seems a bit silly to knowingly break literally thousands of addons for… what?
Because at some point, 32-bit support is going to be dropped from OSes, and we'll need emulators to run 32bit software? Yes, it's still a ways off, but it will happen.
Also, turning doubles into long doubles could be quite interesting for orbiter. Except I don't think DirectX would even support that...
 
Top