General Question Colors

Tommy

Well-known member
Joined
Aug 14, 2008
Messages
2,019
Reaction score
86
Points
48
Location
Here and now
One possible reason Martin keeps it closed source is to prevent forks, as Heilor pointed out. Forks (Orbiter Clones, diverging branches) would be bad for Orbiter for a couple reasons. Right now, we enjoy hundreds of add-ons created by many people. If there were different forks, some developers would make add-ons for one version, others for another version, etc. The end result is each version would have less add-ons than Orbiter currently does. It also helps prevent him from being swamped by people sending in code that may or may not help, and having to spend all his time sorting through it instead of actually working on the code himself.

There have been many open source projects that have forked themselves to death. Only a few projects, like Blender, have truly benefited from forks. Blender's "official" fork, Toohupoo (or something like that) was used for testing new ideas. Ones that work were then incorporated into Blender. An unofficial fork, Instictive Blender IIRC, also ended up contributing many features such as the dynamics that allow water or cloth simulation. Usually, though, forks simply split the developers into separate camps until none of the forks has enough people working on it to succeed.
 

cjp

Addon Developer
Addon Developer
Donator
Joined
Feb 7, 2008
Messages
856
Reaction score
0
Points
0
Location
West coast of Eurasia
One possible reason Martin keeps it closed source is to prevent forks [..]

It may slow down forking, but it doesn't stop it. There is a certain need for an open source Orbiter, so I think somewhere in the future someone will try to make one (and succeed).

The main argument against forking is probably that interoperability standards diverge. So, the main thing you do NOT want to fork, is the standard. Forking of the software itself is trivial.

Look for instance at OpenGL. Both on the driver side and the application side there are lots of different pieces of software, and for as far as there are no bugs, each combination will work just fine. As long as the standard remains un-forked, forking of a driver, for instance, will not create incompatibility with applications.

But this is of course a discussion on whether forking is a good argument. The question whether mr. Schweiger actually follows this argument remains un-answered.

One final comment: in the open source community, forking is strongly discouraged, for similar reasons as the ones you described. So, it's socially accepted only in exceptional cases, and in other cases the forker is simply ignored.
 
Top