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.
I don't know. I find gittip's model mostly rewards popular coders.
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.
Gittip is certainly going to help more popular coders at first. But that's true with any platform in its early growth phase.
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.
Not only that, Gittip's project pages allow funds to be distributed to the entire team. So even if you're not well-known, if your project is, you can still get some.
You don’t know that the PR was submitted with any knowledge of tip4commit. Would you accept the commit normally? Do you want the very existence of tip4commit to modify your project management? My advice: act as if tip4commit doesn’t exist; they’re just providing a service on the side which you shouldn’t need to worry about.
People have an economic incentive to pick the low-hanging fruit, but eventually there will be none left.
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.
IMO if this commit is useful - accept it. It will reduce the next reward by only 1%. Sooner or later all the simple ways to get tips will exhaust. The project will be a bit closer to perfection. And maybe you will have one more happy developer.
While I love to get documentation updates, the comma thing and semi-colon thing is ridiculous, and in the comma case is less correct in this context. The doc re-org isn't a bad thing, though.
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.
Hey there, that last commit is mine. I won't be getting a tip for it, I just thought it was a nice change. The first thing I usually look for with a tool like this is how to install it, so I moved the Ruby installation steps down to the bottom so as not to bury what I thought was the important bit in the Installation section. Poorly-timed, if anything.
What if this kind of routine trivial fix is exactly the sort that needs to be incentivized to actually happen? This is perhaps an extreme example, but it's also the sort of thing that is both common and vaguely unappealing about open source projects. Everyone's excited to do the big important next feature or blatant bug fix, but no one really wants to do the janitorial cleanup.
What if the merger were able to modify the tip amount?
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...
Hm... Do you mean to allow the merger to specify the value of the commit? E. g. by default it could be 1%, but merger can make it smaller if commit is not very valuable. Sounds like a good idea, thanks!
Interesting idea. Here's a twist: what if the committer could set the value of their commit instead? Social pressure would dictate that most people would not overreach. Then those who make small but useful commits could recognize in advance their minor nature. This is essentially a kind of honour system.
That's actually a good idea; you'd probably get fairly reasonable results that way. The downside: using those tags at all makes it unambiguously clear that you care about the tip4commit tips.
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.
I have submitted similar pull requests to open source projects with no financial incentive. I don't really see the problem, as long as it's judged to be a "legitimate" correction.
Projects like these is where Bitcoin can really shine.
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?
Someone on Reddit made a bot that implements this functionality site-wide. You can say "+/u/bitcointip @Username $1" in a comment or message, and the bot will send $1 worth of bitcoins out of your balance to that user. If they don't have a Reddit Bitcoin wallet, it creates one when they get sent coins. The bot also has denominations of beer ($3.64), coffee ($1.38), and internet ($0.25).
Yeah, /u/bitcointip is a great example of what I'm talking about.
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.
What is preventing USD from being used in this way? It seems to me to only stumbling block are regulatory and security restrictions. If that is the case, wouldn't future bitcoin regulation put an end to this type of use case?
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)?
Micropayments is a really tough business. Basically it's too risky. Chargebacks are often anywhere between $15 to $35 per transaction.
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).
It's fairly easy to send USD online if you own a credit card and bank account, but receiving money is a whole lot harder. It's also harder to do it with the degree of anonymity that Bitcoin provides and without the risk of your payment provider freezing your funds or banning you from using their service.
An IP address is light-years from a real-life identity. Without a warrant, there's not a chance of figuring out even the account holders name-- which could be different from the person who actually performed the transaction. It could be a neighbor, a friend, a roommate, anyone else who ever had the wifi password, the possibilities are endless.
If anonymity is a concern getting a court order doesn't sound like a big deal. Even if not, you vastly overestimate the anonymity an IP provides, and if anonymity is a concern legal deniability isn't a big win either. You also ignore that you could potentially get dozens or hundreds of IP addresses. Anonymity, like security, is hard, and has layers.
Anonymity is not a binary variable which is why I worded it "degree of anonymity". I think it should be obvious that credit cards and bank accounts are vastly less anonymous than Bitcoin.
> It seems to me to only stumbling block are regulatory and security restrictions.
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.
What you describe kind of sounds like a universal karma system (yay internet points!). As stackoverflow and similar sites have shown, people will do quite a lot to accumulate internet points.
Not really. You can't purchase karma. Or rather: karma that you could purchase with dollars and use to gratify someone or incentives a task would be akin to a specialised currency.
I like the idea of prepaying bit coins on bounties [presumably tied to an issue/bug report in GitHub] which is what I thought this was at first. As is seems a bit confusing, are all commits treated equally? I'd be peeved if I donated money then saw it get split up among people who did minor clean up, typo fixes, etc. Flip side, I'd be peeved if I spent a bunch of time on a commit then saw the same money go to someone doing a typo fix level commit.
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.
You are right. But it is not a salary, it is just a tip. If developer spent time to make even a tiny useful commit - that is good. Probably with time it will become harder to find tiny commits. And donations will probably keep accumulating thus creating higher incentive for more complex commits.
Especially that the payout is higher for earlier commits, and easy fruit gets picked first.. chances are the hard bugs would not get fixed (or to be an optimist: this would identify what the hard bugs are) and the owner could put an explicit bounty on each of those.
I hate to be a party pooper here, but if this project would ever take off, and the project would receive serious amounts of bitcoin that would mean that serious amount of bitcoin would have to be managed and secured by whoever runs that project.
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)
If only there was some party out there that could protect us from things like this. Possibly even insuring us in the case of something going really wrong and the person holding our money loses it all. They could also establish rules that anyone holding money would have to comply with in order to be certified as safe. Wouldn't that be grand...
It would be grand indeed. It would even be more grand if a small project like this would be able to partake in that party's service without paying thousands of dollars for audits, registration fees, insurance fees and such.
But perhaps it would be more grand if that expensive and bureaucratic third party could just be avoided with a smart technical solution :)
I was not actually, I was talking about how expensive it is to be a bank.
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.
My criticism was on the idea that so many bitcoin proponents put forward that not having any central controlling or regulatory body is a strength of bitcoin. Even if we ignore all of the macroeconomic issues this might cause, you still lose a lot without any regulations. This particular example is the complete lack of consumer protection in any dispute you encounter when dealing with someone in bitcoin.
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.
You can add consumer protection systems on top of Bitcoin; they just aren't forced on every transaction. Even the protocol itself has features that facilitate escrow and similar protections. And the public ledger allows you to prove that you sent BTCs to someone without having to use a third-party service to independently verify that.
Yes, it is a risk. Same question partially answered here: https://bitcointalk.org/index.php?topic=315802.msg3910308#ms... . If project gets traction then most of the collected bitcoins will probably be stored in offline wallet (and hopefully 5% fees would allow to cover losses in case of a hot wallet hack).
Escrow is only really viable if you know the future recipient or if you can depend on the sender to return to approve transactions. Seems difficult to fit it to this type of situation.
Awesome! It looks like a virtuous circle for both open source & the bitcoin network. Really hope this will take off.
However, in my opinion, you should definitely switch to mB (mili-bits), and please add retina icons for the readme. I just added one of my projects there (github.com:mgcrea/angular-strap), this will be quite interesting to watch!
Can someone more familiar with $BITC explain how Bitcoins can be portioned? I get that each bitcoin is a unique number - how can 0.4 of a number belong to someone and the other 0.6 of that number belong to someone else?
There are really no "Bitcoins", there are only a very long series of inputs and outputs to various Bitcoin addresses, all recorded on the shared block chain. Inputs (Bitcoins) come in to the system through mining, and then they are traded out via outputs and in via inputs.
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.
Bitcoin transactions have a fundamental unit which is much smaller than a whole bitcoin. Actually it's 1/100,000,000 XBT! These tiny units are called satoshis, after the creator of the bitcoin protocol.
A bitcoin doesn't have a unique number at all. The unique number that you are thinking of is effectively an "account id". When bitcoins are mined, essentially a ledger gets created saying that "account id" #1234567343533 has 25.000000000 bitcoins in it. When you send someone money, you say "from #1234567343533, send 0.05000000 BTC to #111111111, and 24.95000000 BTC to #1234567343533"
The same way that you can send someone part of a dollar. The atomic unit of USD isn't the dollar, it's the cent (setting aside some financial instruments). Likewise, the atomic unit of BTC isn't a bitcoin, it's a satoshi (1 * 10^-8 bitcoin).
The unique number that you're thinking of isn't the bitcoin itself, it's the proof that that value was yours to spend.
I assume it's not affiliated with the projects at all. This is an independently-run tip system for open source projects. Cool idea.
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.
By all means, please do keep taking a percentage as a sensible funding model; it doesn't seem at all unreasonable, and it ensures you'll stick around. I'd be more concerned if you didn't have any obvious revenue stream.
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.
I am glad you have thought about it it to this extent. It is always reassuring to see that the relevant point have been thought of, and that there is at least a provisional plan to deal with them. This gives me a fair amount more confidence in what you are doing.
If I am reading it right, the developer of tip4commit will never pay out the full balance since they will only ever pay out 1% of the remaining balance. It almost sounds of this site is just a clever way for their developer to increase their position in bitcoin speculation.
Our initial idea was that each donation pays for 30 days of tips (and rewards depended on interval between commits, see http://blog.anonymousads.com/2013/10/tip4commit-first-bitcoi...). But that idea appeared to be more complicated and a bit unfair (consecutive commits could receive very different amounts). So we switched to a simpler one. Yes, mathematically speaking, there will always be some money in our wallet. But we don't expect to have huge amounts of money there since donations are never stable and some projects have dozens commits daily.
This seems like an accidental perverse incentive. While you only get the top if your commit is accepted, I would be worried the maintainers will just end up with a bunch of low effort trivial patches.
the solution is probably a moving-knife procedure[1]:
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.
Is this operated with some sort of commit hook or done manually by the project maintainers or what?
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?"
I'd like to drop $500 to $1k for git-annex into tip4commit. This is money that was donated to me in a crowdfunding campaign (http://campaign.joeyh.name/) and set aside to get more people committing to git-annex than just me.
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.
Arguably, you might want to exclude the BTS and website from the tipping system (or give them a separate pool to draw from), if you're trying to encourage code contributions. Not that website changes aren't valuable, but it's far too easy to make a dozen commits to the website as a natural part of cleaning it up and working on it, especially given the way wikis allow live edits of only a single page at a time.
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?
Thanks for your question. Currently it will just stay as unclaimed balance. But probably it is a good idea to return it back to the project eventually.
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.
I've evaluated using tip4commit, and I need either
* 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)
]
That just looks like an icon to reinforce that "this is a GitHub project". It doesn't at all draw attention to the fact that clicking the icon is the main way to get to the GitHub page.
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?
So could I add comments from junk accounts and earn $4 in bitcoin? I'm not sure I'm following the logic here... and what prevents highly unethical behavior.
maybe tips per number of lines changed would be a fairer benchmark than tips per commit. I guess that would still cause a bunch of unnecessary line changes.
I really don't think this kind of financial incentives are good for open source projects.
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.