Oh! raising my hand. I like it!

What features do you have in mind, exactly? As for open source, look at Linux bloatware (oh wait, I think I see your point of "exponential growth" here).

If Orbiter goes open source, it will die within 12 months.

Could you all explain me why open sourcing Orbiter is a bad idea? It seems that a vast majority of developers and users don't agree. If I missed something, please let me know.

open sourcing a piece of software ain't as easy as uploading your code and yelling "y'all come 'round and dig in!" - well, you CAN do that - but it just might get you into a nice painful licensing breech if you happen to include needed code from third parties (very common)

me thinkings doc Schweiger wouldn't fancy that all too much

then you're bound to whatever constraints the most-constrained license you include may have... if something says "do not redistribute"... well, then you don't


and he may have his own reasons too... who knows, it's his code, he can do whatever he wants with it (except the faults mentioned above) - and given the absolutely formidable work he's done with it so far, i dare not utter a questioning word to his choices

plus, if ppl started each making his own brew of Orbiter, pretty soon we'd have a major userbase split and everything would be sucked down into a vortex of incompatibility and mayhem - and that would be bad



anyways - the SDK is so comprehensive, and the graphics clients open so many doors - who really needs open source when we have all that?

from my year-or-so of experience with orbiter addon-rigging, i find theres very, very little that could be accomplished with the sources that we could not do via the SDK someway or another....

There is open source and there is open source.
Big successful open source projects are commonly centralised, with a core team to make the decisions. Kinda like what Orbiter is now - addon developers making features, good doc tending the core.

What would Orbiter gain from going open source?
Linux port? Too late for that.
Better expandability? Good enough already, any better and compatibility will collapse.
Project survival in case of author existence failure? Well...
More popularity? Perpendicular to development model.
More developers/oftener releases? Somewhat doubtful.

What is your expectations of open source Orbiter?
Who, what, when, how?

Sure, open-source would be great, as you rightly say.

But... I know of at least 2 projects that suffered as well as gained from being open-source.

One, FlightGear, was badly ripped off by a commercial clone that basically took the sources, renamed it, and sold it off, only leaving FlightGear with a small mention. Orbiter has already had several Ebay attacks (search "Orbiter for sale" on the forum) and open-sourcing may just make it a sitting duck to these crooks who want to make cash out of others' hard work.

Another's dev team was kind of split up by open-sourcing, and I'm not sure that losing Dr S is an awfully good idea.

So yeah, you're absolutely right, it would be great and could do good things - it's just that the downsides need to be considered too!

i cant believe this discussion came up,martin has stated clearly that this will not happen in his interview(i'm too lazy to provide a link)

Here's the link: http://techhaze.com/2010/06/intervie...tin-schweiger/

I am a big fan of Open Source, and it's worked quite well for many projects, such as Blender.

However, I fail to see an advantage of opening Orbiter. The core is the only part that is "closed", and with it's very generous API there's plenty of ability to add to Orbiter. Everything from vessels to graphics clients can already be added - and these add-ons can be Open Source if they choose.

Few developers will have the expertise in physics and spaceflight required to be of any use in developing the core, so there's really very little potential advantage to opening it. There is a very real danger of forking - and that has killed many a project.

Forking is especially devastating to software that relies on third party add-ons. Chances are the forks won't be compatible for long, and the 3rd party dev pool ends up getting split between the forks. That means less add-ons for every individual fork.

Martin works on Orbiter in his free time, having to become a "project manager" for an Open Source Orbiter would be extremely time consuming. That means he would have much less time - if any - to develop for Orbiter himself. I suspect that would take all the fun out of it for him, and put him in a position where his managerial duties take up more of his time than he really has to spare. He does have a real job (which is important, and helps save lives), and a life of his own.

look at it from another side: You were working on a program for 10 years. It was your passion and hobby. You are still developing it and would you to decide to open soure of your wonderfull program for the whole world? What if someone turn your simulator into a stupid space shooter and sell it? Wouldn't make you angry. I think that's why Orbiter isn't open source.

Anyway. I think Martin should open source of Orbiter, but not for whole world but only for the trusted persons(like great add-on developers like Dan or Doug Beachy?). It would get Orbiter to make it better in shorter time(it's like building a tower- more people working- less time spent to build it).

I agree. I think that both approaches (open et closed sources) have pros and cons that makes them equal in general. However, for Orbiter and its extensive API, I don't see why it should be open source. Of course it would be a great source of knowledge for all developpers, but would it worth the "lost of control" that an open source project can create ? It's a risk. I think that Martin made the right choice.

Open source is very frequently dirty power play by h@cks: https://lwn.net/Articles/423702/. And, if anyone wants to learn astrodynamic simulation from the code, GMAT's code is fully open.

I am worried that there's no core updates since 101016. Looks like Martin has no time for it or has problems implementing new features. I think he should give access to core for trusted developers.

Shepard, this is NOT true, and to have a glimpse of what's going on simply look at recent postings by Dr.S. And, pray, who are those trusted developers anyway and why should they need access to core engine? Methinks you are omitting the most significant item - substance. WHAT NEEDS FIXING? WHERE'RE THE BUGS, LEBOWSKI? <gg>

There are no public releases, which doesn't mean there are no core updates. There are only no new beta releases of internal builds to public.

You may have noticed in some bug reports: "This will be fixed in the next beta", or screenshots from wind implementation, or shuttle's pad update shown in Orbiter Screenshots thread.

Sorry, I don't have enough time to read the entire forum, especially in recent weeks (even no time to play ). Thanks for explanation.
Anyway, a team of several people can make things much faster than a single man. This team could include the most experienced addon developers, who are familiar with Orbiter internals and other necessary stuff - people like Artlav, jarmonik, developers of UMMU, UCGO and some others.
For example, Artlav made several addons that could be integrated into the core (Orulex, volumetric clouds, some collision engine), but as addons they are unstable and incomplete.
By the way, terrain generation and collision physics are most awaited features for me, but with current development model I'm not sure they will be ever implemented.

I think Orbiter is open enough. It is not completely open-source, but Open API, and most of the surrounding infrastructure is open-source. There is nothing to gain from also making the core of Orbiter open-source. Aside of nasty comments about martins historic code. (Oh yes, I would like to see it)

The main argument I want to give against open source Orbiter: The biggest open source projects in orbiter are badly needing collaboration, and it is VERY hard to get people for that. The core team of SSU did just grow by one developer per year, if you want a statistic. And it sure isn't because nobody is interested in SSU, many people simply don't feel like they want to contribute or simply can't contribute.

As far as I know, the other open-source projects suffer from the same problems.

I would even go so far to claim: Without big industry paying full-time programmers for the big open-source flag ships, open-source would be a purely scientific affair.

here are two things that interest me in Orbiter being Open Source:

- security of the code - I hope that it's shared between the trusted members just in case of accidents ... Else, some even poorer forks would have to emerge for all the addons that are out there
- running and developing on Linux - as long as it runs on Wine, it's OK with me. What I'm missing is the ability to compile addons with MinGW.

Now, thanks to ArtLav, you have the notional ability to compile add-ons with gcc cross-compiler...