I like this low level approach - the upcoming CIYAM open source project's first application is a higher level one that allows donators to contribute BTC to a project, project area or specific project task (with the more general donations being moved by their respective owners down to specific tasks).
Devs can then "bid" to get the exclusive rights to perform a task by a given date and time (so devs aren't in a "race" against each other as happens with "bounties" which IMO generally lead to lower quality code being submitted). If a successful pull request for the task is submitted by the dev by the agreed delivery date and time then the funds will be sent to their address. If unsuccessful then bidding is opened again. A record of past "achievements" is kept in order to help the task "owners" decide which bids they will accept (i.e. preference to be given for those devs with the proven skills and track record for completion).
This system also then ties in with an escrow system that allows people to donate to specific tasks provided they are completed by the date and time that was accepted by the task owner for delivery (if no successful pull request merge occurs by the accepted date and time then funds are returned to the donators).
This system is going to go live very soon (PM me for the URL for a demo if interested).
Topic: [IDEA] paid open source, pay for beer (Read 631 times)
In the words of Richard Stallman, Free Software as protected by the GPL license uses the word "free" as in "free speech", and not as in "free beer". I propose to create a license for "non-free beer", so that programmers would make money on their free-speech software.
I propose to create a license and a set of tools to allow people to make money on patches that they submit to software. This would be a system compatible with open source flow of code on github. Simply, add an ID to your code (lets call it "Beer ID"), which legally can not be removed (just like GPL legally can not be removed). A set of tools for each language environment will be provided to make it easy to pay for the code. For example, for ruby, such a tool can be published as a package "beer", similar to rake, added to Gemfile. Then, the user of the code will be able to do this:
$ beer list cancan
token-id git-commit-hash amount currency mode
123 abc... 1 USD per_year
...
$ beer set --account xyz
$ beer pay
The "pay" command will pay all money owing. It will keep track of previous time it was executed, and will compute exactly what is required. Eventually, it will be automated to run with Bundle install.
Why is this needed ? It takes the analogy of bloggers publishing content, and putting ads -- into the space of source code. The incentive for people to pay for open source, rather than cheat, is that people want to do naturally the right thing. In this case everyone recognizes that programmers should make money, and that is why "gittip" is in business.
More should be said about the "mode" and "currency" parameters. Currency can be USD, or Bitcoin or some virtual currency with no value, like points. In the latter case, it would represent simply a counter of how many people use the software. As for the "mode" parameter, it can be per time period, or once, or per execution. To keep track of execution, the marker in the code will not be just a commend with an ID, but will actually be a function that will have to be "legally" executed upon startup. It can be just invoked in module scope when it is loaded.
Most importantly, it would allow developers to sell their code contributions. Pull requests would be rejected if a contributor wants to charge too much for it. This use-case gives another idea for "mode" variation: it can be "merge" only. In this case, once the code change merges, the Beer ID is removed.
Finally, the --account have many configuration options, one for Bitcoin, another for Paypal, etc. It is the account from which user will pay. The user will manage his account from a site that promotes the Beer License, or direct options are possible to directly pay (say, from Bitcoin) for all the different beers.
I propose to create a license and a set of tools to allow people to make money on patches that they submit to software. This would be a system compatible with open source flow of code on github. Simply, add an ID to your code (lets call it "Beer ID"), which legally can not be removed (just like GPL legally can not be removed). A set of tools for each language environment will be provided to make it easy to pay for the code. For example, for ruby, such a tool can be published as a package "beer", similar to rake, added to Gemfile. Then, the user of the code will be able to do this:
$ beer list cancan
token-id git-commit-hash amount currency mode
123 abc... 1 USD per_year
...
$ beer set --account xyz
$ beer pay
The "pay" command will pay all money owing. It will keep track of previous time it was executed, and will compute exactly what is required. Eventually, it will be automated to run with Bundle install.
Why is this needed ? It takes the analogy of bloggers publishing content, and putting ads -- into the space of source code. The incentive for people to pay for open source, rather than cheat, is that people want to do naturally the right thing. In this case everyone recognizes that programmers should make money, and that is why "gittip" is in business.
More should be said about the "mode" and "currency" parameters. Currency can be USD, or Bitcoin or some virtual currency with no value, like points. In the latter case, it would represent simply a counter of how many people use the software. As for the "mode" parameter, it can be per time period, or once, or per execution. To keep track of execution, the marker in the code will not be just a commend with an ID, but will actually be a function that will have to be "legally" executed upon startup. It can be just invoked in module scope when it is loaded.
Most importantly, it would allow developers to sell their code contributions. Pull requests would be rejected if a contributor wants to charge too much for it. This use-case gives another idea for "mode" variation: it can be "merge" only. In this case, once the code change merges, the Beer ID is removed.
Finally, the --account have many configuration options, one for Bitcoin, another for Paypal, etc. It is the account from which user will pay. The user will manage his account from a site that promotes the Beer License, or direct options are possible to directly pay (say, from Bitcoin) for all the different beers.
Jump to: