After our discussion, here's a diff I made to the Indiegogo.
-Will CPS be a turn off for consumers and users of my code?
-
- Depends at what enforment level you will specify the price. If the enforcement
- level is "none", then a payment would be a volunatry donation. If set to
- strict, the payment is required. Between "none" and "strict" there are many
- variations. For example, "30-trial" would be a 30 day trial.
-
Added this:
---
Is there legal enforcement of payment?
Although this would be good, CPS will not be able to make such
enforcement practically. If the toolset is not installed because
of lack of awareness or on purpose, no legal action is taken since
it would be impossible to track it, or differentiate between the two.
The overall CPS system is voluntary according to the following analogy.
Today anyone can download music on Bittorrent for free, yet people buy music
on iTunes. If you download a song on bittorrent, no legal action will be
taken against you.
A developer at a company may get a prompt "please install and
configure CPS to use this gem". He will escalate this to his
supervisor, and there's a good chance that the supervisor will
say "yes". Or the prompt can say "you will need to setup CPS
within 30 days". Many developers don't know if the library is
what they need, until they integrated it and tried it.
However, if the programmer will monkey-patch to short-circuit the CPS toolset,
he won't end up in court.
Companies however are used to pay for software, and because CPS
is designed to bring large amounts through micro-payments, the
amount for an individual company will be comparable to a taxi expense.
Companies also do not want to deal with mods, but prefer
to work with standard packages. Unlike an individual developer, they won't
bother hacking a CPS toolset.
Implications for Bitcoin
A CPS provider may support many currencies, but Bitcoin is a great
choice for CPS. It has dual benefits for both CPS and the overall
Bitcoin community. For the latter, companies that use OSS code
will have to buy some bitcoin. Imagine the possibilities! The
more people use Bitcoin the stronger the currency is.
For CPS Provider Bitcoin offers a cost free way to transfer funds
and avoids the need to hold users money in centralized accounts.
It also allows offline operation as described later in this document.
Ethics of Charging for Software
As Richard Stallman, the number one person in Free Software
movement explained, the word "Free" is like in "Free Speech", not
"Free Beer". There is nothing wrong with releasing your code with
GPL license, but still charging money for it.
Here's some background. The Open Source (OSS) movement claims
that it is more practical to distribute software and provide its
source code. The Free Software movement (FSF) claims that it is
not only impractical, but also unethical to distributed software
without source code. Despite this difference in motivation, many
OSS projects are released with the GPL license that FSF developed.
Ethical implications of CPS is that if you're making money through
CPS then your dependencies must make money as well.
The FSF claim that distributing software closed source is unethical
has created a taboo in the OSS community against any change that
even remotely resembles the world of closed source commercial
applications. That is why majority of OSS work is free as in "Free Beer".
The taboo disappears when one understands the philosophy of the
claim that closed source is unethical. The claim is equivalent
to the statement that knowledge is a basic right. If this were
true, then you are obligated to tell everything you know to any
stranger, including your passwords. Actually, the confusion here
is between knowledge of invention and discovery. If a discoverer
of a law of nature announces his discovery, he can't expect others
not to capitalize on it. An inventor, however, can protect his
work because it is his creation. Consequently, a programmer can
choose to publish his work with open source code, but nevertheless
charge for its use.
Reference: http://aynrandlexicon.com/lexicon/patents_and_copyrights.html
Payment Amounts
In additional of fixed amount, and percentage, there can be a
setting based on rating, popularity, complexity or simply
line-count. Most of this can be figured out automatically by
the system. For example, the popularity of the package is just
the number of times it is a dependency in other projects. Rating
can be retrieved from hub sites collecting ratings and reviews.
Complexity can be estimated with data-theoretic algorithms.
Stock Option Model for Pricing
A CPS provider may issue stock options. The option gives its
owner a right to use a certain package as dependency at some
price point (use/cascade values). These options can be traded,
and the rules of economics will generate optimal evaluation and
price for free software.
Git Integration
Instead of adding a CPS line to the source code, it will be possible to set git author configuration to mark
automatically patches with CPS information.
Topic: Cascading Payment System (Read 1361 times)
Thanks for the response, actually this reply is much better than how it reads on your original indiegogo post. It sounds much more reasonable, practical and useful, and I am finding myself agreeing with all of it.
You may want to clean up some of the wording on Indiegogo however, as an example from the Indiegogo post, this section:
)
The better answer is one you gave here (not the same question exactly, but close):
Making it sound like something the developer will want to incorporate to help fund future versions of the software instead of something that evokes nasty shareware makes it come across completely differently. I know it's a big part of the proposed system, but I would think about not even mentioning the strict part in the context of open source libraries until getting to the 'Enforcing CPS Usage' section.
Especially since your target indiegogo audience is developers who are already not making enough money from open source, to try to get development of the system funded to pay them will require some serious ninja marketing skills.
You may want to clean up some of the wording on Indiegogo however, as an example from the Indiegogo post, this section:
Quote
Will CPS be a turn off for consumers and users of my code?
Depends at what enforment level you will specify the price. If the enforcement
level is "none", then a payment would be a volunatry donation. If set to
strict, the payment is required. Between "none" and "strict" there are many
variations. For example, "30-trial" would be a 30 day trial.
(also, from a marketing perspective, for the question 'is X a turn off for my users' the answer should always be 'No' or 'Of course not!', never 'Depends...' Depends at what enforment level you will specify the price. If the enforcement
level is "none", then a payment would be a volunatry donation. If set to
strict, the payment is required. Between "none" and "strict" there are many
variations. For example, "30-trial" would be a 30 day trial.
)The better answer is one you gave here (not the same question exactly, but close):
Quote
CPS will make no such enforcement -- if the toolset is not installed because of lack of awareness or on purpose, no legal action is taken. The overall CPS system is voluntary and suggestive. A developer at company X may get a prompt (in the strict case) -- "please install and configure CPS to use this gem". He will escalate this to his supervisor, and there's a good chance that the supervisor will say "yes", and this dev shop will get a bitcoin account! Or the suppervisor can say -- "is there a legal issue to work around it?" and in this case the answer is "no", so they will monkey-patch a few cps lines to skip these prompts. Or the prompt can say "you will need to setup CPS within 30 days". Many developers don't know if the library is what they need, until they integrated it and tried it.
Making it sound like something the developer will want to incorporate to help fund future versions of the software instead of something that evokes nasty shareware makes it come across completely differently. I know it's a big part of the proposed system, but I would think about not even mentioning the strict part in the context of open source libraries until getting to the 'Enforcing CPS Usage' section.
Especially since your target indiegogo audience is developers who are already not making enough money from open source, to try to get development of the system funded to pay them will require some serious ninja marketing skills.
Thanks or valuable feedback, and taking the time to write it. You raise good points.
There is definitely a philosophical shift here that is required to make in the OSS community that software costs money. Any kind of human work has value. Here are the reasons why programmers contribute to OSS today:
- they found a fix for a bug that they need, but do not want to maintain it -- they prefer the main tree to integrate it
- it boosts their professional credibility in job interviews
- educational and fun, or in other words, recreational
We could conclude that these three incentives are enough, since they have been working so far. However, with the advent of the iPhone app store, and the flurry of activity there we see that programmers want to make money off of their evening work.
The key question here -- is CPS going to force something or make it optional, like a donation ? I came to the conclusion that it must have the "forcing" element somewhere in it, because we already have many voluntary donation systems. The forcing element is two fold:
- if you're making money through CPS, then your dependency must make money as well.
- use of patch may require to get onboard with CPS (enforcement strict)
With enforcement set to "none" the system degenerates into a hierarchical Flattr system. The strict option is there because nothing like it exists today, and that is my main goal with the CPS project, namely, to allow people to make money on OSS contributions. The "none" option is there or a slower adoption path, that you want. Those contributors who have nothing to loose, will set strict on their patch. Those projects that don't want to force anything, will set "none" on their CPS, or not have CPS at all (which essentially means "none"). But an occasional $20 donation through CPS will be spread to dependencies with 'none' setting and will begin to shift people's view of OSS that software can cost micro-payments.
As well, I don't see that a requirement to install something is a problem for a developer. If the developer is working on a Ruby-on-Rails project, he would need to install a gem. This is consistent with his development process -- simply add another gem in Gemlist file. Moreover, cps gem can be installed automatically as a dependency when a certain gems are installed.
Likewise, if installing through apt-get, cps .dpkg can be installed automatically for some packages that marked it is dependency.
Since there is already a dependency structure for many pieces of software, a CPS toolset can work with that graph directly and require no "lines" to be added to the source code in these cases.
Finally, you are correct to say that at some point the developer will have to take action for dealing with the money issue. If cps toolset works with Bitcoin, the developer will need to get some -- which will be a great thing for spreading Bitcoin!
Or he would fund some online account with whatever currency specified in CPS conditions.
It is a good idea to use Git email instead adding explicit line in the patch. Git can also have configured a bitcoin address, or any CPS identifier. However, I don't know if GitHub pull requests take this info into account. This would be a good add-on feature for environments when you know that your git setup will propagate the info correctly. However, an explicit comment is the most generic way to do it, at least for the purpose of defining CPS spec.
Also, git is not always involved. What if someone gives you a solution on StackOverflow that saves your day? The solution could have the provision comment in it which you will integrate into your code.
The project owner will have to sign up for something to receive the money (let's say Flattr), and to setup something to distribute it (some toolset to distribute the money). A CPS toolset provides both in one package, and can work with Flattr as well (as described in CPS Option section).
I'll conclude that we need something like App store for OSS. There's no reason why a silly app on app store makes thousands of dollars, but authors of OSS software (e.g. Qemu), libraries (e.g. KVM kernel driver), critical patches and StackOverflow solutions make no money.
I think the gist of your idea has merit but the barriers to adoption with your proposal are way too high. Any developer that has to install something or get users to install something wouldn't work well for a kickback-style system. It has to be easy, painless, require no thought, and be automatic if possible. For both the developer and the end user. No installs, no registration, no extra stuff to think about when writing code or pushing patches.
There is no way you can enforce someone paying for open source software I would think (except legally, or with great programming hassle) and I don't believe it is in the spirit of open source; also interested users can donate directly to the project as well. A closed source project, or one that requires payment for Windows binaries, sure, but those are handled by existing methods already.
There is no way you can enforce someone paying for open source software I would think (except legally, or with great programming hassle) and I don't believe it is in the spirit of open source; also interested users can donate directly to the project as well. A closed source project, or one that requires payment for Windows binaries, sure, but those are handled by existing methods already.
There is definitely a philosophical shift here that is required to make in the OSS community that software costs money. Any kind of human work has value. Here are the reasons why programmers contribute to OSS today:
- they found a fix for a bug that they need, but do not want to maintain it -- they prefer the main tree to integrate it
- it boosts their professional credibility in job interviews
- educational and fun, or in other words, recreational
We could conclude that these three incentives are enough, since they have been working so far. However, with the advent of the iPhone app store, and the flurry of activity there we see that programmers want to make money off of their evening work.
The key question here -- is CPS going to force something or make it optional, like a donation ? I came to the conclusion that it must have the "forcing" element somewhere in it, because we already have many voluntary donation systems. The forcing element is two fold:
- if you're making money through CPS, then your dependency must make money as well.
- use of patch may require to get onboard with CPS (enforcement strict)
With enforcement set to "none" the system degenerates into a hierarchical Flattr system. The strict option is there because nothing like it exists today, and that is my main goal with the CPS project, namely, to allow people to make money on OSS contributions. The "none" option is there or a slower adoption path, that you want. Those contributors who have nothing to loose, will set strict on their patch. Those projects that don't want to force anything, will set "none" on their CPS, or not have CPS at all (which essentially means "none"). But an occasional $20 donation through CPS will be spread to dependencies with 'none' setting and will begin to shift people's view of OSS that software can cost micro-payments.
As well, I don't see that a requirement to install something is a problem for a developer. If the developer is working on a Ruby-on-Rails project, he would need to install a gem. This is consistent with his development process -- simply add another gem in Gemlist file. Moreover, cps gem can be installed automatically as a dependency when a certain gems are installed.
Likewise, if installing through apt-get, cps .dpkg can be installed automatically for some packages that marked it is dependency.
Since there is already a dependency structure for many pieces of software, a CPS toolset can work with that graph directly and require no "lines" to be added to the source code in these cases.
Finally, you are correct to say that at some point the developer will have to take action for dealing with the money issue. If cps toolset works with Bitcoin, the developer will need to get some -- which will be a great thing for spreading Bitcoin!
Or he would fund some online account with whatever currency specified in CPS conditions. On to Using CPS with Patches. This I could see working, but not by adding 'pay me!' cruft to the source code which no project will want. Instead:
- People donate directly to a project using BTC (of course) directly to a receiving address for the project. This address could be managed by your website as well and makes it easier for the disbursement part.
- All developers already have email addresses in the code, that they are using during commits.
- On each major new release of the code, or every $accounting_period, distribute the funds according to some distribution (size of patch? stability of developer with project? uniform?) to each registered developer's address or a temporary wallet stored on your site that then they can redeem by proving they are that person (email? GPG?) or by donating expired payments back to the project's pool.
- People donate directly to a project using BTC (of course) directly to a receiving address for the project. This address could be managed by your website as well and makes it easier for the disbursement part.
- All developers already have email addresses in the code, that they are using during commits.
- On each major new release of the code, or every $accounting_period, distribute the funds according to some distribution (size of patch? stability of developer with project? uniform?) to each registered developer's address or a temporary wallet stored on your site that then they can redeem by proving they are that person (email? GPG?) or by donating expired payments back to the project's pool.
It is a good idea to use Git email instead adding explicit line in the patch. Git can also have configured a bitcoin address, or any CPS identifier. However, I don't know if GitHub pull requests take this info into account. This would be a good add-on feature for environments when you know that your git setup will propagate the info correctly. However, an explicit comment is the most generic way to do it, at least for the purpose of defining CPS spec.
Also, git is not always involved. What if someone gives you a solution on StackOverflow that saves your day? The solution could have the provision comment in it which you will integrate into your code.
Quote
So it would be like an automated btctip bot, for open source. But this way there is no requirement for a project to even sign up to get the benefits, and users can donate without any software or sign-up.
The project owner will have to sign up for something to receive the money (let's say Flattr), and to setup something to distribute it (some toolset to distribute the money). A CPS toolset provides both in one package, and can work with Flattr as well (as described in CPS Option section).
I'll conclude that we need something like App store for OSS. There's no reason why a silly app on app store makes thousands of dollars, but authors of OSS software (e.g. Qemu), libraries (e.g. KVM kernel driver), critical patches and StackOverflow solutions make no money.
frisco2, I am assuming this is your link... I'll steer it back onto the topic of using Bitcoin directly for the sake of the forum, and provide some criticism. Feel free to correct me where I am misguided...
I think the gist of your idea has merit but the barriers to adoption with your proposal are way too high. Any developer that has to install something or get users to install something wouldn't work well for a kickback-style system. It has to be easy, painless, require no thought, and be automatic if possible. For both the developer and the end user. No installs, no registration, no extra stuff to think about when writing code or pushing patches.
There is no way you can enforce someone paying for open source software I would think (except legally, or with great programming hassle) and I don't believe it is in the spirit of open source; also interested users can donate directly to the project as well. A closed source project, or one that requires payment for Windows binaries, sure, but those are handled by existing methods already. There are lots of legal and accounting challenges involved with getting the cascading part right and proving fairness so I'll skip that. Also when CPS Inc. calls up J Random Business out of the blue asking for money for open source software in strict mode you will have some interesting conversations, since developers usually don't take those kinds of calls, and management will have no clue what a 'jquery' is.
I think the way you have proposed the CPS part in example 1 and 2, you can do all of the same with bitcoin URIs, (i.e. Like this software? Consider donating 0.05 BTC here: donate!) that popup during the install or software execution.
On to Using CPS with Patches. This I could see working, but not by adding 'pay me!' cruft to the source code which no project will want. Instead:
- People donate directly to a project using BTC (of course) directly to a receiving address for the project. This address could be managed by your website as well and makes it easier for the disbursement part.
- All developers already have email addresses in the code, that they are using during commits.
- On each major new release of the code, or every $accounting_period, distribute the funds according to some distribution (size of patch? stability of developer with project? uniform?) to each registered developer's address or a temporary wallet stored on your site that then they can redeem by proving they are that person (email? GPG?) or by donating expired payments back to the project's pool.
So it would be like an automated btctip bot, for open source. But this way there is no requirement for a project to even sign up to get the benefits, and users can donate without any software or sign-up.
Anyways, good luck with your project and it would be nice to have something like that but I think that the method as proposed requires too much adoption on both sides to be truly useful.
I think the gist of your idea has merit but the barriers to adoption with your proposal are way too high. Any developer that has to install something or get users to install something wouldn't work well for a kickback-style system. It has to be easy, painless, require no thought, and be automatic if possible. For both the developer and the end user. No installs, no registration, no extra stuff to think about when writing code or pushing patches.
There is no way you can enforce someone paying for open source software I would think (except legally, or with great programming hassle) and I don't believe it is in the spirit of open source; also interested users can donate directly to the project as well. A closed source project, or one that requires payment for Windows binaries, sure, but those are handled by existing methods already. There are lots of legal and accounting challenges involved with getting the cascading part right and proving fairness so I'll skip that. Also when CPS Inc. calls up J Random Business out of the blue asking for money for open source software in strict mode you will have some interesting conversations, since developers usually don't take those kinds of calls, and management will have no clue what a 'jquery' is.
I think the way you have proposed the CPS part in example 1 and 2, you can do all of the same with bitcoin URIs, (i.e. Like this software? Consider donating 0.05 BTC here: donate!) that popup during the install or software execution.
On to Using CPS with Patches. This I could see working, but not by adding 'pay me!' cruft to the source code which no project will want. Instead:
- People donate directly to a project using BTC (of course) directly to a receiving address for the project. This address could be managed by your website as well and makes it easier for the disbursement part.
- All developers already have email addresses in the code, that they are using during commits.
- On each major new release of the code, or every $accounting_period, distribute the funds according to some distribution (size of patch? stability of developer with project? uniform?) to each registered developer's address or a temporary wallet stored on your site that then they can redeem by proving they are that person (email? GPG?) or by donating expired payments back to the project's pool.
So it would be like an automated btctip bot, for open source. But this way there is no requirement for a project to even sign up to get the benefits, and users can donate without any software or sign-up.
Anyways, good luck with your project and it would be nice to have something like that but I think that the method as proposed requires too much adoption on both sides to be truly useful.
I like this idea, but it would be hard to keep hackers from inserting their own BTC addresses.
Can you please clarify what do you mean?
How is that different from hackers inserting any arbitrary code into software that people download ? It doesn't happen because pull requests are reviewed before they are merged into the main tree of a project.
I like this idea, but it would be hard to keep hackers from inserting their own BTC addresses.
Why is this posted on the bitcoin forum ?
Bitcoin can be one of method of payment. Actually, the most logical one. In offline operation, it would just print a list of bitcoin addresses, and you will pipe that to a script that will run bitcoin command to deliver the payments.
Why is this posted on the bitcoin forum ?
I would also like to know, Troll thunder cat doesn't agree.
Why is this posted on the bitcoin forum ?
Jump to: