My thoughts about a collective have included a bidding system. For each project, the coordinating team identify the work units. For each work unit, the collective's members may submit a bid comprising of:
* time available to work on project (start date, commitment, etc.)
* time estimates
* profit-sharing margin
The project coordinators choose a best fit.
All assets created by the collective are added to a common pool and may be used in a bid by another member for a different project with the original creator getting a cut of that project's profit.
That's an awesome idea, using a kind of market to decide the price/profit. You need some kind of reputation to make this work, you don't want any fool bidding and then not doing the work.
It's a design I've been tinkering with for while and have a bunch of notes about. Reputation would be handled by a transparent history of all projects worked on.
The profit-sharing design does not prevent collusion. E.g., if there are a glut of programmers and a shortage of artists in the collective, then two may collude to submit and share a low programmer bid and a high artist bid (and vice versa on another project).
Collectives are hard and are subject to many problems that the free market does not suffer.
Ya that's my thought too. The logistics of running a business are different (and in my mind easier to solve) than the logistics of programming, and should be solvable in a more general way. Also there is a social aspect to it. It's pretty obvious in any project who is pulling their weight (at least for people on the inside).
Why is this downvoted? "License an open source formula based on the value of short/long contributions" sounds like LOC to me. Dividing income fairly is the core issue. Solve that and the rest is easy. The problem is that this is very hard.
Also, unfortunately I think income is also a difficult split to have happen. If you are looking for scale, at some point, some investment will be needed. Even with scalable resource architectures, two co-founders can only answer so many customer communications. That recapitalization will need to be factored in based on a communally accepted baseline. In essence, you can factor in a unit-based investiture that pays out dividends on meeting certain business liquidity scenarios and operating rules. Those units can be sold or traded at will, with new buy in "partners" accepting the new operating license of the business. Remaining unit holders vote changes to the operating license.
I give it 4 months and the SEC will come knocking, guaranteed.
Yea I don't think lines would work ;) If bloatware was bad, just imagine. Short/Long contributions refers to the short term and long term implications of contributions from software developers. Company produces product to solve problem. Product contributions in no particular order or coherence: 1) Long term smart growth-focused architecture 2) Long term product strategy 3) Short term code quality (bug count) 4) Short term, feature suggestion & consumption ratio 5) Customer vs. Company/Product satisfaction rating to solve problem 6) Software's Resource Utilization 7) Customer speed-to-solution average, etc, etc.
* time available to work on project (start date, commitment, etc.)
* time estimates
* profit-sharing margin
The project coordinators choose a best fit.
All assets created by the collective are added to a common pool and may be used in a bid by another member for a different project with the original creator getting a cut of that project's profit.