______  
(  ___ \ 
| (   ) )
| (__/ / 
|  __ (  
| (  \ \ 
| )___) )
|/ \___/ 
         

     #   
         
    ##   
     #   
     #   
     #   
 #   #   
  ###    

         
         
 # ###   
 ##   #  
 #    #  
 #    #  
 #    #  
         

   ##    
   ##    
  #####  
   ##    
   ##    
   ## ## 
    ###  
         

 _______ 
(  ___  )
| (   ) |
| (___) |
|  ___  |
| (   ) |
| )   ( |
|/     \|
         

IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now.


Visit Preferences to set your user name
Summary of change:
'''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 ofbiz.org (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). * product genboard * product firmware * product genboard association (type "Engineering Bill of Materials") to 20 "pieces" of firmware. This means firmware takes 20% (if the BOM sums up to 100) of vem's profit from genboard sales (the distributor party and installer have their own profit of course). Note that "Engineering BOM" is independent of the "Manufacturing BOM". The firmware is subdivided (but neglect this for now) to * core design * straightforward design * coding * testing 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. TODO: * make a report so every developer sees their own shares from each product's sales: <code> 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 ); } </code> notes: * It's OK for now to leave out the outer foreach party...; * tricks (like in-memory hash) might (and should) be used to make the processing faster. Calculating all the shares in one go is faster than recalculating all the time (this can be achieved by caching calculated data in hashes). ---- '''Limitations''' * developers prefer to keep credit in the store for usage later. This is fine and simple: however I don't see how it is possible to apply a few % interest rate technically, so any such investment is motivated. Maybe when calculating the current inventory for a product and facility (only for when the shares are calculated) the inventory-variances summing procedure could consider the time of the inventoryvariance. ---- '''Logical spec: old terminology before the physical mapping was created (above)''' * Activities: this is the main object in the system (maps to product in ofbiz). 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 * a marketing activity, * a unit-sale activity * and a support activity 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). ---- ''''Examples''' 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. * 5000 * 0.1 Euro will go to A * 5000 * 0.05 Euro will go to F 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. ---- '''abstract''' An '''activity''' has: * '''type''': this determines some basic parameters (eg. forces a certain amount of percentshare - see below - owned to other activities) * '''manager''': who configures the variable parameters and supervises the activity (eg. confirms credit assignments) * a frequent '''report''' that tells incomes, total credits, and basically everything about the given activity (so one can verify that he got his share, and make his own future expectations). * '''income''' can be direct, or coming from other activities An '''activity's income is divided''' between: * '''direct costs''' (materials, shipping, loan-payback, etc..). * '''percent share''': the remainder (after direct costs are subtracted) divided (usually between contributing activities but possibly accounts too) according to percentage factors (this is mainly useful for other activities and loan-fees for loans that supported an activity risking money) * the remainder after the division according to percentage factors (that usually sum to <100%) will be divided according to the '''credits'''. 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: * Basically the income part needs to booked to activities, (originally called accounts, but activities in our context) (well: simple, but important part!) * and the business infrastructure helps account for the direct costs. * Also, account balance can be used to buy stocked stuff instead of getting money out of the system (this has nice advantages for tax perspective). ---- '''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 [http://java.sun.com/xml/jaxb/users-guide/jaxb-using.html JAXB] 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: * someone might not want to take out money ASAP when the income share was assigned, but leave in, those values should naturally increase with a rate. A rate must be higher if it is settled for a predetermined minimum time. This helps financing activities in the system, as some activities needs cash (eg.: manufacturing and stocking) not only intellectual work. * one is interested in what his share will be according to his credits if incomes and further work will be according to (a pessimistic, realistic or optimistic) plan. Of course if more work is needed than projected (so more credits are assigned finally) or incomes are less than expected, it will be different, but at least it gives an idea in Euro units. * when credits are reevaluated (eg. someone claims his balance should be higher, and the manager confirms) or other percentages are adjusted, in the worst case it can effect earlier income distribution. Naturally, any adjustment that effect distribution of past income must be well-based - so must adjustments that effect future. '''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
Optional: Add document to category:
Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.