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.
Ask HN: Co-Ops for Developers?
11–20 of 23 posts
Re: Ask HN: Co-Ops for Developers?
#12Here 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.
Re: Ask HN: Co-Ops for Developers?
#13How 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.
Re: Ask HN: Co-Ops for Developers?
#14Who 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'…
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.
Re: Ask HN: Co-Ops for Developers?
#15Re: Ask HN: Co-Ops for Developers?
#16Earlier quoted context omitted.
Programmatically. License an open source formula based on the value of short/long contributions against a revenue / equity model.
Do you mean based on number of lines of code?!
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.
Re: Ask HN: Co-Ops for Developers?
#17How 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…
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.
Re: Ask HN: Co-Ops for Developers?
#18Who 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)
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.
Re: Ask HN: Co-Ops for Developers?
#19Earlier quoted context omitted.
Do you mean based on number of lines of code?!
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.
Re: Ask HN: Co-Ops for Developers?
#20Earlier quoted context omitted.
Do you mean based on number of lines of code?!
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.