Earn $4 in bitcoins for any commit to sferik/t, a command-line Twitter tool
tip4commit.com
tip4commit.com
If there was no financial incentive, I would probably merge it but now I'm questioning the motivations of the committer. If I merge this, it means there will be less money for someone else, who makes a more significant contribution in the future.
Personally, I prefer Gittip’s model to incentivize open-source contributions, if only because it doesn’t create this kind of noise for project maintainers.
Where as tip4commit, rewards are not influence by popularity. I do see how fluff pulls could drain the pool. One needs to ask: Is changing a typo worth $4 dollars? Is it worth my time to do it? Maybe I should just click that merge button.
In my opinion bountysource is the best reward system, as it gives context, popularity is a boon, and it shouldn't generate fluff.
Just my two cents.
When Gittip is more well-established, anyone who wants to should be able to put a "Gittip button" on their project page. When Gittip itself has more name recognition, an unknown coder who creates a widely-used project should be able to rapidly pick up meaningful support through Gittip.
A project could have a standard of, say, 0.5% for typo fixes, 1% for documentation, 2% for refactoring which improves Code Climate or coverage statistics...
One plausible possibility that might help: in the block that normally contains Signed-off-by and Reviewed-by, add a tag for marking a commit as "minor" or "trivial", in the sense used by the Linux kernel's trivial@ patches or the GNU project's threshold for changes accepted without copyright assignment.
And as a quick hack, scale the tip by log(diffstat) with a sensible upper bound.
Personally, I wouldn't mind accepting something like that for my own open source project. It takes time to proofread, and I appreciate spotless grammar.
https://github.com/sferik/t/pull/142/files
https://github.com/sferik/t/pull/143/files
https://github.com/sferik/t/pull/144/files
Shameless.
But, I also suspect that once there are lots of projects that have this feature, and the maintainers establish that they won't merge non-useful commits, like grammar nitpickery (though good grammar has value, and we merge stuff that fixes grammar in our docs, and I wouldn't mind having people get paid for it) this would become less common. And, reputation still matters. I wouldn't want to be "that guy" (and I wouldn't want to hire that guy for substantial work) that takes advantage of a simplistic system to get paid.
Maybe Bitcoin will conquer the world, maybe it won't. I have no idea.
What I do know is there is real utility in being "electronic petty cash" which Bitcoin can easily become.
Imagine: Alice sends Bob a few bitcoins after Bob writes a particularly insightful comment on HN. Bob then comes across a great blog post by Charlie and sends him a few bitcoins. Charlie then finds an open-source project by Diane that will save him hours of work and sends her a few bitcoins. And so on.
It rarely would get converted to USD and wouldn't amount to much when it did. Instead, people would just earn a bit here and spend a bit here.
Bitcoin enthusiasts miss that USD works fine for most people. But right now it's really hard to do the above scenario using traditional banking. I don't want to connect my bank account to some website to send a someone a few bucks. It's just not worth the hassle/potential risk.
I can't be the first person to think of this. But I'm just not seeing much movement in this direction. Am I overlooking something? Or do I just need to be patient?
Or: money is tradable karma.
Or is the real benefit of your proposed use case the distance of bitcoin value from perceived financial value (ie you are willing to tip X bitcoin but have second thoughts when looking it as X cents)?
Yes, the addresses are public, but there isn't a way to prove who's who according to addresses alone.
Unless of course you publicly attach your identity to one.
When you earn a small percentage of a $5 transaction, which a sender claims to have sent by mistake (or he/she requests the money back due to different reasons) 2 things happen:
A. You lose your % of $5
B. You get charged $35.
Not a pretty situation to be in when you are scaling and about 15-30% of your sales get charged back.
Bitcoins are irreversible, so at least they mitigate your risk as a micropayment provider (or as a seller).
That's correct, but those are humongous only's.
> If that is the case, wouldn't future bitcoin regulation put an end to this type of use case?
Short of large-scale Internet traffic examination, the only thing regulations can hope to do is restrict the exit points: the exchanges between Bitcoin and some government-controlled currency.
Though I do wonder how the more vocal Bitcoin supporters would react if the project never grew beyond "electronic petty cash," even if it was successful at being that (i.e., widely used and easy to set up).
My worry is if Bitcoin "fails" in its larger goals (e.g., challenging the USD's global domination), it'll be seen as a failed project which will keep it from even being able to accomplish its smaller, more manageable goals.
Don't know if the whole intrinsic/extrinsic motivations factor will make this idea crater in any form but I think tweaking the current model is advisable in any case.
Best of luck.
The past has shown that everyone, even persons who run e-wallets and currency exchanges, severely underestimates the amount of security such an endeavour requires.
There's a hundred questions you should ask anyone who asks you to keep care of bitcoin. How large is the hot wallet? How is the offline wallet stored? Where's the source code? What hardware does the service run on? Who are you? What will you do when someone steals your hot wallet? What monitors do you run to make sure the books add up?
So, nice idea, but please make sure this is actually going to be safe.
(BTW there seems to be a way to escrow bitcoin where a third party decides if the transaction should pass, but that third party never gains access to the bitcoin themselves, I haven't read the details of it, but that would seem perfect for this sort of thing)
But perhaps it would be more grand if that expensive and bureaucratic third party could just be avoided with a smart technical solution :)
A bank account of course solves all those things, but because of the nature of bitcoin it's rather hard if not impossible to realize the financial system we know as banking using Bitcoin instead of government controlled currencies.
So if he was indeed talking about a bank account, then it was a sneer towards Bitcoin itself, and he'd be quite right, the banking system solves this problem very well.
I still think the three party transaction system would be preferable even to banking, if it can be done.
Instead of trying to improve on the monetary policies and regulations that exists around the world, bitcoin simply tries to replace them and leave nothing in their place. It is like going from the current US government to anarchy. There are a lot of things that can and should be improved in the old system, but that doesn't mean we should throw it completely out and have nothing to replace it.
update: fixed a mistake (online to offline)
The unique number that you're thinking of isn't the bitcoin itself, it's the proof that that value was yours to spend.
The smallest value for an input/output is 1 Satoshi. 1 Bitcoin equals 100,000,000 Satoshi. So a Bitcoin is just a convenient measurement of inputs minus outputs.
When you make a purchase from an address, the client adds up your inputs and outputs at that address, and if you have a positive balance, you can send any portion of it as an output to another address (as long as you have the private key to verify that you own the sending address). It is recorded on the block chain as an input to that receiving address records, and the miners (eventually) confirm that transaction by including it in a block -- each time that happens is 1 confirmation (mining is another whole can of worms).
When you make a purchase that is less than the total number of inputs minus outputs at the address you're spending from, you can receive the difference via an input to either the same address or another, new address, depending on the Bitcoin client used.
Does that make sense? It's all just a shared accounting system.
EDIT: Clarified role of block chain.
Key disclaimer though, is that only 95% of donations for tips go to the coders. And if every commit donates 1% of the balance to the commit, that means that the project almost never donates it's full balance. So if this ever really takes off, the original developer of tip4commit will be holding a lot of money that takes a long time to pay out.
We made this project as a part of Rails Rumble contest and are using a limited-time free server offered by them.
So we need to collect money to move to a new server, to cover transaction fees and to continue development of this service if it is demanded.
Maybe we should remove the fees, go opensource and crowdfund ourselves. We were discussing it but haven't made such decision yet.
We don't expect to hold large amounts for a long time because large amounts should attract dozens of commits every day (and thus will turn into small amounts quickly).
If it doesn't happen then we will probably introduce a fixed minimum size for a tip or some other mechanism to solve this problem.
Probably it is good to hold money for some time and to smooth the tip rewards thus placing authors of commits into nearly equal position.
Alternatively, if you do make your site open (and that'd be awesome, please do), you should prominently encourage people to post tips to your repository.
We haven't got any outside donations yet, but I think it would be quite a good way to reward contributors, and I put a bitcent in to try it out.
have a list of rewardable issues. grow the reward for each issue with time. once the reward makes the time spent on the project worthwhile, people will be incentivized to commit. they won't let the reward grow too high, for fear that someone else will take it.
you could let coders freeze the reward for some amount of time, and get exclusive rights to claim that reward, until the time expires.
Not sure this is intended behavior.
Shouldn't the owner of repositories be out of scope (or at least make it configurable)? tipping myself minus the commission is no fun ;-).
PS: would make sense to have a signup via github
Edit: At present this is obviously an MVP that is probably being completely "faked" on the back-end, so I suppose my question should be "What is the intended design?"
For the record, I thought MVP because I somehow didn't notice all the other projects and thought this was the only one.
Problem is this: git-annex's website and indeed its BTS are part of its git repository. So it gets lots of commits from eg "name@web". I don't want tip4commit to try to send bitcoin tips to such dummy email addresses.
Is this something your platform can handle? It would be sufficient if the emails you send have to be acted on to take bitcoin out of the tip pool, and it otherwise remains available for the next committer.
BTW, a@ai is a valid and IIRC actually used email address. :)
PS: Thanks for your hint regarding valid email addresses. If your email address is a@ai or something similar - you won't receive tips, sorry.
* The ability to prevent specific email addresses being tipped. * Or the above-mentioned returning unclaimed balance to the project.
In my use case, I make a lot of commits, but I am entirely interested in sending the tips to committers who are not me. If I use tip4commit in its current state, I'll deplete the tip jar quite quickly, and not likely attact more committers.
Running some numbers, I have made 200 commits to git-annex in the past week. If I seed the tip jar with $1000, after a week I calculate I will have been tipped $866 back out of it to myself. After 2 weeks, only $18 will remain in the tip jar!
Hope this can be improved; it would be a pity to have to roll my own, and this otherwise seems exactly what I need.
[quick haskell program used to simulate it:
main = print $ calc 0 200 500
calc :: Float -> Int -> Float -> (Float, Float)
calc totalout 0 tipjar = (totalout, tipjar)
calc totalout n tipjar =
let payout = tipjar/100
in calc (totalout + payout) (n - 1) (tipjar - payout)
]Could tip4commit support configuring a single repository to treat commits differently based on what paths they change?
As an aside, if you added a full name to ikiwiki's Preferences, couldn't you construct proper commit authors using full name and email for anyone who supplied them?
Only 15 projects with a nonzero tipjar at the moment.
How about making the link cover the entire header ("sferik/t" and the octocat icon), or adding a "View project on GitHub" link under the description?
If you provide a value-less commit, they'll just ignore it, and you'll get no money.
If you provide a bunch of value-less commits, they'll probably get annoyed.
If you provide a commit worth merging in to the project, they'll likely commit it, and you'll receive the tip.
It's the first time I see a full year streak!
I really don't think this kind of financial incentives are good for open source projects.