From Game Editor

There is no magic bullet, there is no free lunch in software development.

If a software developer needs any other way to get payed besides your own work in the software development, the software can stop evolving.

The dual license model

In order to keeps the good developers working in the Game Editor we choose to use a dual license model, with the GPL v3 for open source games, and a payed license for the others.
By using a dual license system, We want to create a self supported open source model, by selling a license to users that's won't to create open source games, sharing the revenues with the developers that's have contributed to the code. The users that's create GPL games can use the software without pay anything.

With this model, Game Editor will continue to evolve for a long time.

How to share the revenues?

The way to share the revenues can be based on a score system.

Today, there is a score system in the Game Editor forum that's works very well. The score system is based on a vote process. If some user likes the post of other user, can give a point to him. What we can see is there an user with a high score is a very good user that's helps others in the forum.

Now a score system must be created for the developers of Game Editor. But how a developer can earn a vote (score point)?

How good is a software?

Think about how software users says to the software developers that their product is good.
If they like the software they will USE the software! If not, just will uninstall and search for a better solution.

So, if the software is not good, there are only one choice: The software creator needs to make a better software.

How good is a developer's code?

We need a way to measure how good is a code in the same way that's the user measure how good is the software!

So, we can use the follow concept: The code is good if it is used!

And we can measure whether a compiled code is in use and know which developers worked on that code.

If you want, you can even know the the percentage of used code produced by a developer in the whole software usage.

The key is to have usage statistics of the basic block of the compiled code.
By using this statitics, there are two methods to know how to share the revenues:

• The first method to share the revenues by using the code usage data is by using the information if the basic block is in use or not. So, we can just share the revenue with all developers that's have used codes:

Amount received by each developer = Total of Revenue / 
(Number of developers that's have code used by the users)

• The second method to share the revenues, is to consider the number of times that's the basic block is used. In other words, the number of times we have a basic block executed is the user's vote for our code! So the share will be:

Amount received by the developer D = Total of Revenue * 
(Number of times of execution of all basic blocks created by the developer D) / 
(Number of times of execution of all basic blocks created by all developers)

Is the process fair?

The second method is good because  the developer will be payed by how good the user think your code is.
The problem is we can have a lot of developers writing code for only few parts of the software (the hot parts). But if this happens the hot parts can becomes more cold and push the developers to write other codes and new features that's can attract the users.

The first method is good, but can upset developers that's have worked hard in a lot of codes and will be payed with the same amount of the other codes that's have write only few block of codes.

By using any of the described methods, the developers can get the payment by using a system like PayPal.com that's available in many countries.

May be there is no way to make the revenues share completely fair.

But the process described here can be very close to it.