Ask HN: Co-Ops for Developers?
22 comments
Who determines product direction? Aside from the challenge of estimating developer contributions ("I wrote the core services" vs. "I wrote the money making feature of the day" vs. "I wrote the analysis / AB test tools that let us optimize"...), how would you split revenue among non-coding contributors (including artists, for example)
>Who determines product direction?
Everyone submits ideas, some voting and discussion takes place, then people work on what they want to work on.
Splitting equity and revenue is a much more complicated issue. In my experience it's easy to figure this out for small teams, provided the members are reasonable and can appreciate each other's work.
There was a software startup that was trying to do exactly this but I can't remember what it's called. Quirky is also doing this, albeit for tangible products, and they have an interesting approach.
Everyone submits ideas, some voting and discussion takes place, then people work on what they want to work on.
Splitting equity and revenue is a much more complicated issue. In my experience it's easy to figure this out for small teams, provided the members are reasonable and can appreciate each other's work.
There was a software startup that was trying to do exactly this but I can't remember what it's called. Quirky is also doing this, albeit for tangible products, and they have an interesting approach.
That's cool. Ya I was thinking that it would have to work similar to real employee-owned companies. There would be votes to determine tiers of pay, or equal pay for everyone (which I personally don't think is fair, after pulling about twice the weight fixing computers at my last job). The more perceived "fairness" for all parties involved, the better the talent that will be attracted. This kind of flies in the face of for-profit decision making, where the owners and shareholders are given more priority than the workers.
On issues of product direction and a whole host of other decisions which aren't practically decidable by "let's vote everyday," it seems reasonable that the collective would elect from within a chairman who would hold office for some previously agreed upon period of time before the next election, say two years. Etc.
The logistics problems aren't the big difficulty to me. To me the activation energy, so to speak, is where it gets tough. Who starts the thing? How does it get rolling and profitable such that you could get people to do such a thing.
The logistics problems aren't the big difficulty to me. To me the activation energy, so to speak, is where it gets tough. Who starts the thing? How does it get rolling and profitable such that you could get people to do such a thing.
A stackoverflow like "proposals and voting" might work. Perhaps you'd want to make the proposing anonymous to get a vote based on the content of the proposal rather than on the person who proposed it.
I've thought about something similar along the lines of a developer cooperative with incubator leanings. People could work on their own projects or together on joint-projects or on consulting projects. Non-technical abilities like branding, marketing, SEO, etc etc could be handled by folks willing to work with anyone in the co-op (in the same way that a large media company will share common skills across brands). Risk is reduced by providing an environment where people can share knowledge and skills. The big questions is how you share revenue and handle management.
I've been thinking about something like this for a while.
What I picture is something like elance or rentacoder with a mix of sourceforge (or the like).
Projects could advertise for members, and use the site for hosting the source, bug tracking, wiki, etc. Plus, the site could, if it were a commercial product, act as a payment processor and distribute collected funds according to some set of percentages or rules.
Projects could advertise for members, and use the site for hosting the source, bug tracking, wiki, etc. Plus, the site could, if it were a commercial product, act as a payment processor and distribute collected funds according to some set of percentages or rules.
It looks like some software projects are getting kickstarter.com funding. Interesting idea.
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.
* 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.
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.
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.
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.
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 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.
Here is the receipt:
1. be awesome
2. start a company
3. make that company successful
4. morph the company to play these rules
And report back.
And report back.
In my own career, I can say that without a doubt, the employees were more competent in their endeavors than their employers. They just suffered from a lack of funds or the freedom to do their calling (whether from family obligations or past debts).
I just keep thinking, if there was a project like Mozilla that I could contribute to from home, and then if it was sold/supported similar to Red Hat, the programmers could split the earnings. Whoever contributes the most, could take the largest split of the profits. I don't see elance or other sweatshops as the future of programming, because they are limited to working at the level that employers expect. We should be able to work at our level and create income streams appropriate for our expertise.