Hacker News Reader

Comment by jules | Hacker News Reader

How are you going to determine who gets how much?

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.

Programmatically. License an open source formula based on the value of short/long contributions against a revenue / equity model.

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).

Do you mean based on number of lines of code?!

Hopefully not LOC since it can be very easily abused.

Ya, the fewest lines of code submitted is often the best result (counterintuitively).

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.

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.

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.

I forget who it was, but there was a car factory that worked like this:

Groups no larger than 6, reporting to higher groups of 6, up to how many levels you need.

Within the groups of 6, they work out themselves who gets paid what, completely transparently.

The amount everyone gets paid is posted publicly. It worked, because people set the rates fairly in the groups.

If your going to do something slightly anarchistic like be by developers for developers you might as well go the whole hog.

Oh, also make sure the whole organisation isn't bigger than 150 at any time - staying within the dunbar number seems like a great idea.

Reply on news.ycombinator.com