Since there are many people here doing work that (besides fun) has high value for others, we want to make sure that all get their fair share.

See MakeMoney for a brief, simpler explanation. Actually, the user-view of the thing should go there, and the technical details stay here.

When quantities are small, it can be done by feeling, but as sales is boosted we need some organized way and software support so it's as efficient (low overhead) and fair as can be.

Because it is not possible to coordinate all efforts by one person, we set up VemsExecutives.

Distribute the load - distribute the profit

Imagine that helping 10 thousand people needs a way of distibuted work (and compensations likewise). A primitive scheme like a unified mailing list is very inefficient for helping (burns a lot of resources for a given amount of help). The wiki is far superior, but some people like some guidance especially at the beginning. Often on-site support is required. We want something superior that is friendly for people (end user, support-chain, developer, etc..).

Representing shares in (physical mapping)

Marcell and Jason did some mapping of our scheme to ofbiz. It seems ofbiz has premade relations that map very well. Custom entities would be very easy to define, but reports would take more time.

Let's cast light with an example (numbers are out of the air).

Note that "Engineering BOM" is independent of the "Manufacturing BOM".

The firmware is subdivided (but neglect this for now) to

Here is the trick: the product firmware (built by mik, cell and dave) is NOT represented by engineering BOM type product associations to "firmware_mik", "firmware_cell" and "firmware_dave".

Instead mik's, cell's and dave's shares are represented as inventory: mik's facility has N pieces of firmware (we increase the inventory as mik improves firmware). This makes it easier to assign "credits" (just inventory) along the way. Some kind of approval will be needed later, and linking to workeffort.

There is a little one-time cost compared to using engineering BOM for the credits, but maintenance will be much simpler.


foreach party (in a given partyGroup){
   facilityX = first facility that belongs to the party (in given role?);
   foreach productP {
      xsum = 0;
      pshare = 0;
      foreach productT {
          x = engineering_BOM_quantity(productT, productP);
          xsum += x;

      // iterate again on all products, we have the xsum by now
      foreach productT {
          x = engineering_BOM_quantity(productT, productP);
          xpercentage = x / xsum;

          tinvsum = totalinventory_in_all_facilities(productT);
          tinv = inventory(facilityX, productPT);
          tpercentage = tinv / tinvsum;
          pshare += tpercentage * xpercentage;
      print share_of( party, productP );



Logical spec: old terminology before the physical mapping was created (above)

An activity is a cost center and a profit center at the same time.

For example someone who has a car-repair shop (not a requirement, just an example) can choose to sell, install and support GenBoards (or other stuff that has VEMs intellectual property). He'll probably have

The activities are linked under other (we can sloppily say higher level) activities, since they use the services of those. So some of their profit will be delegated up. We call this delegation a share: activity A has a share in activity B if B uses the services of A. Share in the activity (=product) is represented by inventory (yes).


For example support activity B earns 6000 Euro, but 1000 Euro is consumed by direct costs (maybe parts or shipping). Activity A (which is a documentation activity) has 10% share in B, and activity F (which is a firmware activity) has 5% share in B.

If the activity owner chose to contribute documentation work back (or we can say up, but there is no absolute up/down direction in the whole system, just in the relation between 2 activities) to activity A he'll get a credit in activity A so he'll get a share from the 5000*0.1 part as well, but more importantly from the future profit (note: historical data management is needed) of other activities that activity A will have a share in. This encourages people to contribute, and share their knowledge and knowhow to utilize a bigger market than they could otherwise gain. But at the same time the activities should be profitable locally, in the short term (except some higher level activities, like the creation of firmware that does not generate local profit, but when the unit sales are realized).

We measure the work done for an activity's purpose in credit The credit only make sense for that particular activity, basically a weight: the profit left in that activity (usually the major part is left in the leaves, not consumed by direct costs or delegated up according to the shares) is simply shared according to the credits. The activity is like a logical company, but very low overhead. Legally it is realized by licensing-contract (where the licence fee is slightly more complex than in the simplest case, like it was described above, but it worths it for the gains).

There will be a very small part that goes to the founders-activity, a group of about 10..15 people taking shape these months (got a few already :-)

Activities should be able to be cloned simply, if something similar is needed, but the weights must be changed (because of new players or different profile). Weights could also be simple formulas referring to other weights.

The app needs a right (and authentication) system for assigning weights (in a top-down scheme).

Job tracking: for an activity (let it be high or near the leaves in the tree), there can be a job list. People can apply for subtastks if they

want to take part.

Some reports are needed, and interface to manage sales data (that is linked to activities) that goes into the system.


An activity has:

An activity's income is divided between:

The credit is a way to assign given account's shares in the system for work done. As work progresses, the total amount of credits for an activity increases, but the income normally increases even more progressive (as repeating something is easier than doing it for the first time: if large part is done automatically, it is much easier).

So the credits don't lose their value, but the percentage (from the income) it means is not constant either. The credit-shares usually go to real accounts (although there won't be anything that prevents activities to be configured to get credit based shares)

An account holds credits from the activities it directly participated in (1 credit in one activity might have a totally different nominal percentage than 1 credit in another activity, obvious from the above).

Note that credit is not a fix Euro (or USD or other currency) value, but a measure to split income. A nonzero credit brings money to it's owner every time a relevant sale is realised.

It represents someone's (an account's) contribution to the success of an activity.

prototypes as shorthand

The above structure is simple (the simplest that is still suitable to do a good distribution), but very flexible. For managability, facade activities are practical. A facade-activity is an aggregator of several other activities. Like the intellectual-property can be a facade activity that owns 30% of sales, but intellectual-property is a facade activity with only percentage shares (no direct costs and no directly assigned credits) that sum to 100 (eg. 20% hwdesign, 30% firmware, 20% tuningsoftware, 20% documentation, 10% marketing). It helps decrease the connections in the system, reporting and making strategical decisions.

connection with ofbiz

There is some (light) connection with the business infrastructure:

description language

I think it's best to define some XML formats for the above objects.

If we define in XSD (which is for XML), we can use


to pull (or write out) the structures to memory java objects that can be traversed easily (to calculate the things that everyone is interested in - his own account - and other reports for activities).

We originally disallow circles in the graph, or have some simple rules like a share less than epsilon (a very small marginal value like 0.00001) credit or epsilon sum is neglected to prevent infinite loop in processing.

Some webforms are needed for managers and reports with different visibility.

projections for future

we need a bit more than the above to handle:

The future-percentage adjustments between major activities (practically set in facade activities) can help target attention to one area or another: if we think sales-boost depends on tuningsoftware, we can make tuningsoftware activity's percentage higher, so the potential bigger sums will motivate developers to contribute to those areas.

motivation for distributed work that brings success

This distributed system can motivate people to contribute intellectual work, and do everything to put it to use in thousands, or ten thousands, or more instances. At the same time it can fund a solid infrastructure to finance the natural costs that can make the system work (manufacturing, marketing).

See also MakeMoney