
Earn ETH by committing to open source projects - shakedown
https://blog.status.im/introducing-commiteth-enabling-a-community-driven-development-model-52159984c531#.dmpp3zthu
======
duncancarroll
Very cool! Coincidentally, a group of us were just discussing this idea over
lunch today. We also imagined that one could write a package manager which
could link into 21.co and charge some minute amount of BTC / ETH to pull the
latest version of <insert library here>. (HTTP 402: Payment Required) That
pool of money would then be allocated to issues / features / etc, based on how
many upvotes on Github, etc, which seems similar to what you've done.

------
chriswarbo
This is a neat idea, although the implementation strikes me as being rather
bizarre: users of open source projects, which they fetch from a distributed
VCS, can pseudonymously send distributed cryptocurrency to an autonomous smart
contract. OK. The contract releases the funds based on comments appearing in a
proprietary, centralised CRUD Web app. WAT?

------
underyx
Could someone translate the 'How does it work?' section for those of us who
aren't familiar with Ethereum?

~~~
scientaster
Basically a github maintainer can add their project to commiteth so that
whenever someone posts an issue with a label "bounty" a bot posts an address.
That address is an ethereum smart contract. People all around can send ETH to
that address in order to add incentive to the fix. In Ethereum, contracts can
have balances just like wallets.

When a pull request comes in that says it fixes that issue, the bot sees that.
Through the smart contract it authorizes the package maintainer to disburse
the funds to the fixer at the maintainer's discretion.

~~~
chrisacky
Do you have any idea what happens if the smart contract isn't ever fulfilled?
For example, could the reporter create a expiration? Otherwise the
Smartcontract is tied up ad infinitum, and perhaps might never be fulfiled,
hence locking up Ether forever? Any idea how this works?

~~~
scientaster
While I haven't read the contract, that is a definite possibility. Most
applications that require an 'Oracle' (a trusted source of information i.e the
bot) can be written in a way that a deadlock would occur if their service was
down, for example. That being said, a smart-contract can be written to give
refunds in the case of an expiration, disallow the maintainer from cashing his
own pull requests (though he could make another account), and other logic like
that.

It's very powerful; but when the smart-contract world interfaces with the
unpredictable outside sometimes the logic doesn't line up.

~~~
tdb7893
Sometimes I feel like smart contacts solve a set of problems by creating a
whole new set of problems

