Ask HN: Critique this idea
Anyway, I had this idea when talking about a scheme to "reward" people for contributions to an FOSS project. Actually paying people is a bit against the grain (and most FOSS has no financial backing anyway) but it seemed like a good suggestion to have a method to personally reward someone in a serious way. This was also prompted somewhat by a recent link to http://fairsoftware, who's model I quite like :)
So here's the idea. A combination of Twollars and Fairsoftware (and a bit of Tipjoy in there too).
You register your project and get X "shares". As people contribute to the project they can be awarded some of the shares (perhaps there could be SCM integration to give bit-y rewards to lines commited, or perhaps there could be a crowd sourced vote system to decide how much a contribution is "worth" plus, ofc, the ability just to gift shares as and when). These shares have NO money worth - until someone donates to the project.
At which point the owner can set aside a percentage (perhaps that he/she can limit to a certain total amount) for running costs (servers etc.). The rest gets spread out amongst the "share holders".
Instead of actually payiong out the money each holder can select a charity (from a list, or eventually maybe their own) to donate their share too. Their user page shows off how much they have "raised" for the charity.
The contributors get a meaningful reward for their work The FOSS project gets linked to charity work (always good for the image :)) The donators know their money went to worthwhile places (whilst still showing appreciation to the project) The project owner still gets running costs
Thoughts? Is this just an over complicated idea or does it have merit? Are there any FOSS contributors, donators or "owners" out there who might have interest in such a setup?
Go!
Back to the drawing board :D
I've thought of this concept before, and I think the key is to measure based on contributions to functional goals of the project, not amount of code added.
For example, participating in a discussion on requirements for a specific function is worth X points. Submitting the code is worth X points, too. Documentation is worth X points, as is communicating with the end users who requested the function or found the bug.
In short, reward people based on participating in a collaborative development process. Then that 5-line patch is more highly rewarded by someone who takes ownership and truly participates, not just a random coder with time to spare.
Might this discourage some people? Yes... but only people who wouldn't have time or inclination to be significant participants in the project anyway.
In the long run, the team and project should be stronger.
At least, I thi/hope so...
The same thing might even happen to the user base: the software is still free, but now you get a guilt thing for not having donated to Oxfam.
Weird psychology at work here, I'd guess.
That said perhaps there are other avenues: the main point is to not give cash out to contributors because that defeats the object somewhat (in my eyes :D). For example it could go into some sort of software related fund (perhaps like a google summer of code type fund) etc.
I think, we entrepreneurs shape the world around us to tune into new ideas. Persistence and continuous mutation/evolution showed to work for life, why not business too? Whenever someone asks a question here on HN, you get 90% of critiques and ways of discouraging. I say screw them. The spirit of real hackers and entrepreneurs is to just do it, be perseverant and have no fear of failing, but if it is to happen, fail fast and learn from it for the next iteration. No other can influence the success or failure than the entrepreneur himself, so I think you should hear the tone of only those that give you suggestions which way to go. I am sure you know what the problems are.
My suggestion. Build a prototype, use something that you can build it very quickly e.g. Rails and then hear out what the people are saying about it. Then modify it day by day from what you hear, and I guarantee you that you will eventually end up with something great. Your idea might be brilliant or stupid, but it is not on us to judge. Also, when you get discouraged, remember it is not on you either to judge.
I personally believe that is indeed needed and a great thing and has been going through my mind by reading a bunch of stuff. If I can somehow help, I'm in. I recommend you read this, that you would help solve:
http://www.strategy-business.com/press/enewsarticle/enews053...
Cheers!
Dejan/Aleveo.com
You are on the right track, but I would suggest some tweaks.
1. Why does FOSS have to be given away for free? The freedom that RMS talks about is in accessing the source code and improving it. In other words, if you made donations to FOSS mandatory, you'd still have "libre" software, but not "free" (beer) anymore. Is that too shocking a concept?
This could make the amount of money flowing in significant enough that developers could start abandoning their day job and actually work full-time on FOSS. Today, if you look at who significantly contributes to FOSS, apart from a few exceptions, they are all somehow on the payroll of IBM, Sun, Intel or Google. That's not freedom.
2. In our implementation of FairSoftware, we used the paradigm of a corporation, where everyone is a shareholder and decides on future share allocation. To match better a FOSS implementation, I would recommend some sort of karma, where everyone can upvote contributions they like. In large, unstructured groups, it might work better. If I like what you do, I give you a +1. Think of it like HackerNews voting, if you will. This is somewhat subject to gaming, but nothing that can't be fixed.
It would provide a model for allocating the shares that is more in line, I think, with the FOSS community.
Finally, I disagree with the statements that if you start compensating people for contributions to FOSS in any way, you will pollute the well. If implemented improperly, it's true that you can alienate the volunteers. That's why I think the flexible karma approach would fit much better. You can receive karma without having to ask. A good leader will make sure that newcomers are welcome and give them some thank-you points as soon as they help.
On a related note the Capitol Hill Baby-sitting Co-op paper is well worth reading. This has been posted before, but in case you missed it: http://ideas.repec.org/p/kud/kuiedp/0335.html
I'll add: how to fund open source projects is a Difficult Problem. A while ago, there was a great mailing list called FSB (free software business), with a lot of illustrious folks. They never really came to any definite conclusions other than "it's difficult".
Transaction costs (I assume you mean payout to the charity) weould be easy because you just store up the charity donations from everywhere till it reaches a reasonable value ($15 perhaps, or more) then payout costs are minimised.
As to donations - I had a big discussion about that last night. In the end we figured 3 things. Firstly collecting donations is a pain to handle so a lot of people dont bother (especially as there is little worth to them). Secondly there is no culture to donate even though many people probably would if it was easy and they could do it super cheap: a known central service to handle donations wold be recognisable and trusted. Thirdly as a portion of the beneficiary would go to charities and you could actually see that happening it might encourage more people to donate.
In terms of complexity: I think it just sounds more complex than it is. Really it IS just Twollars with a bit more on top.
Does that seem like a reasonable assessment?
What happens when we decide, like businesses, that we need new classes of shares? Who gets paid first? Who has "voting rights"? What's the process to to pursue remedies if you feel you've been cheated, or that the "board" (project owner and his lackeys) has operated in bad faith to defraud share holders?
This is a complex issue even before you hit the psychological problems that others have already raised.
What I'm saying is that shares can't really divided in a trivial, algorithmic way. I like the idea in theory, but I think it's impossible to correctly implement.
The divison would be based on awarded "shares" - so we're not talking stock exchange type shares (dont worry, I play the markets :) Im genned on realistic shares) but "share of the donation"
After I posted the original message I realised it was misworded. The project doesnt get X shares to divvy up. Rather share count is "infinite" and the project owner hands them out (either by automated means or manually) to others. So if 10 people contribute and each gets 1 share they recieve 1/10th of the donation pot (after costs etc.).
If the owner wants a "share" they must give themselves some ;)
Do you think company stocks started out that complex? No, they started out as an intuitive way to divide the profits of a business operated by multiple people, just like your intuitive way of dividing profits from a project built by multiple people.
Edge cases presented themselves, conflicts arose, opportunities for individuals to maximize profit came to light, and thus was our current system grown.
Im not 100% sure I agree the problem would be as dramatic/bad as your presenting though.
P-BOS works best when the modules are small, and hence breaking down individual contributions within a given module does not get too messy.
As to the 'morality' of charging for FOSS, the issue can easily be sidestepped by giving developers complete control of the licensing and payment terms for their modules.
For example, a given module (component) could be free for everyone, or just non-commercial users. Developers should also be similarly free to route a certain percentage (0-100) to charity. The key point is to leave all the key decisions to individual developers.
If anybody wants to know more about P-BOS, feel free to drop me a line: david-lmframework-com
It's possible that there is incentive to be had in the 'common goal'; "The Foo Project's Charity is the FSF; If we squash all the bugs by Labor Day, 80% of donations will go to the FSF. Otherwise, 50%"
(The common goal thing is quite good....)
As a silly example; 1000 Twitter followers would not have been valuable in 2006, but in 2009 it holds a value. It's the same with HN ratings.
An issue there is that new users will feel "at the bottom of the pile", and possibly less likely to "rise up the ranks". At least once a project gets going.