[draft] About This Project
Origin
This project, an accidental invention, came from my experience programming computers for 20 years, followed by publishing an AIDS newsletter for the next 20 (and trying to fund open-access online). I believe that the idea of allowing financial accounts to reproduce is new under the sun, and will be very important. How to make it work was not obvious, and I've developed one system for doing so. The key obstacle now is that the idea of reproducing accounts is so different from what has happened before that people have trouble understanding it.
RepliCounts is ready to go, not just a research suggestion. A small team of top programmers could have limited but useful proof-of-principle system ready in weeks for the public to test and play with. I want to develop these ideas in a free and open-source project, so that anyone can use them (including companies that want to develop their own proprietary software, which we welcome). The goal is to let different organizations compete on quality, services, and cost-effectiveness -- instead of letting one company use the corrupted U.S. patent system to lock customers in by killing innovation and locking competitors out. Of course the open-source development project will need to include at least one practical implementation.
As of early June 2009 I have written and published many descriptions; the early ones were limited systems that evolved into the current RepliCounts. Now I am preparing a more organized, definitive version for this site, www.RepliCounts.org.
No code has been written. If I do it, the software will have to wait until I find time to learn modern programming methods (especially Ruby on Rails), after being out of the field professionally for over 20 years. So my main strategy is to bring the ideas of RepliCounts into public discussion; if people judge the concept workable and useful, then it should not be hard to help organize an open-source project, to create working software quickly.
Proof of principle software will be easier than might be expected, for several reasons:
- It can run entirely on the server, so there is no need to support different operating systems, or install any software on peoples' computers. (A few utilities on the client will be useful, but these can wait.)
- One system on one server can support experimentation worldwide, in many different languages.
- In financial regulation, the direction these days is to make anyone who keeps accounts for others be regulated like a bank, for reasons that are obvious in view of the financial crisis. A possible problem for RepliCounts is not the regulations themselves, but the need to develop momentum in an entirely different field (financial regulation) in order to show the early proof of principle of this software concept. Fortunately, some uses of reproducing accounts will not involve money at all, and these can facilitate early testing. More importantly, most uses that do involve money do not require keeping any of it in the RepliCounts themselves. For example, the sponsorship of prepaid digital content can have money can go directly from the sponsor to the artist, just like ordinary ecommerce -- the only sacrifice from doing it this way is that the end user will not have the motivating knowledge that their free click and download directly pays the artists at that instant. These important uses that do not involve keeping any money in RepliCounts can let companies build business momentum; later, some of them may get a banking license or otherwise meet the regulations, in order to offer other uses of RepliCounts that do involve storing money in them.
- For artists and for many other uses, the RepliCounts system will be useful immediately, with no need to wait for any network effect, any critical mass of users. It simply doesn't matter whether their sponsors and end users know anything about RepliCounts -- so of course they don't need to have any such account. Anyone knows how to click to download free; and anyone who pays money online knows how to do ordinary ecommerce with a credit or debit cars. That's all they need to know. Only the artist needs to know about RepliCounts, in order to use them to sell his or her digital work, with no payment required from the end user. And the artist is motivated.
Privacy
We use Google Analytics, which uses a cookie to track anonymous traffic through our site. We do not collect information on individual users.
Archive
Contact
jj [at] RepliCounts [dot] org
Page above updated 2010-01-17
This RepliCounts™ software design by John S. James is licensed under a Creative Commons Attribution 3.0 United States License.
Translate -- 52 Languages:
Figure 1: A Typical RepliCount
Each oval represents a different, modular service that this account can provide; the uncolored ovals represent services currently turned off. In practice, an account might have several hundred services available, with about 90% of them turned off at any given time.
Figure 2: Account Replication:
In this example the owner of parent account (on top) had it create 3 new "child" accounts -- and the current owners of two of the new accounts have made changes. The owners changed what payment methods the accounts will accept.
Alternative Money Ideas (Search):
Search over 100 sites for ideas on improving the institution of money. See list of sites searched.
About the Author:
John S. James started programming professionally in 1963, and in the early 1980s published articles on the computer language FORTH, explaining it to other programmers. He left programming when a volunteer project led to AIDS Treatment News, an activist medical newsletter that he founded and published for over 20 years.
The RepliCounts project began as an effort the fund the newsletter online. But the design developed unexpectedly into a platform with many possibilities. We encourage discussion and use of these ideas, and have no proprietary claims.