Until our Federal goverment provides paying jobs for everyone who is able and willing to work, or the economy magically achieves zero unemployment, the only way unemployed people will be able to work in return for compensation will be to join a "cooperative" (sorta halfway like barter) system. I'm currently in the process of setting up such a "new economic system" over the InterNet. [current portal here] (Note the updates on Mar.03 and Mar.04, included later in this document, when I realized my system can easily accomodate government-funded work, as well as other sources of funding, in a graceful manner, thus eliminating the either/or logic stated above.)
Note that the key mechanism of this "new economy" (NewEco) will be anyone whatsoever being able to propose a new kind of service they'd like to have provided to them, by posting a "Request For Bid" (RFB) describing one specific new task they'd like performed for them, and then anyone else can bid on that contract. The lowest bidder then is assigned the task, performs that task within the time limit, and gets paid. This mechanism allows *everyone* to be gainfully employed, because of the abundant variety of RFBs they can browse, unlike the current system where the only kind of work anyone can get paid for is where there's some company already providing that kind of service to customers and hiring employees to perform that kind of work.
The "cooperative" nature of my system is that anyone can provide labor directly for my system to gain initial credit, which credit can then be used to post RFBs to hire others. (Some of the services my system provides to users will be dependent on such labor-for-the-system to build up various databases needed by those services.) There will be no limit to how much credit a person can acquire via performing work for the system or by working for others, hence no limit to the number of RFBs and working contracts simultaneously in effect. (There will, however, be a limit on the total amount of un-used credit any one person can accumulate, and a limit on the total value of any single contract. My system will support many small quick tasks rather than any individual long-term contracts, thus force diversity of investment in RFBs.)
At present I'm working on several specific parts of this "new economy", each protected from spambots by a simple "Turing test":

In case you want to code such a Turing test to protect your own Web site, here is a sample of such a Turing test, with a link for seeing its PHP source.

Here is a larger index of services I would like to provide, if I can find people to work with me on their design. (Most of these suggestions pre-date this NewEco proposal by more than one year.)

Update 2009.Feb.24: First draft of proposed policy for access to services.

Update 2009.Mar.03: I realized that the government CCC/WPA (a.k.a. ELR = employer of last resort, guaranteed minimum wage job if no better job is available), and my NewEco described here, can be unified into a single system, with gradual spectrum between the two depending on how much funding is available at any given time. I just need to write this up and post it on a Web page and link it from here, if anybody expresses interest. Then eventually I need to completely merge the CCC/WPA page with this NewEco page to get rid of the apparent conflict between the two.
Update 2009.Mar.04: Furthermore I realized also that donations from formal charities, as well as charitable contributions of gift cards from individual stores or store-chains, fit nicely into this system right along with government "stimulation/CCC/WPA" money, thus making it obvious I need to merge this all into one description rather than have twoXXXfour separate Web pages (CCC/WPA/NewEco/CharityEco/GiftCardEco) which would be quite ridiculous even if the two separate pages is tolerably sensible (or seemed so before I realized the unification was possible).

Update 2009.Mar.05 (local notes from about a week ago, finally uploaded here, to be expanded after upload):

Most urgent major NewEco tasks require low-level software tools to be developed (seeking volunteers to help with implementation of these software modules):

Update 2009.Mar.05 (local notes from a few days ago, finally uploaded here, to be expanded after upload):

Most important/urgent server-side applications within NewEco:

Update 2009.May.01: Russia Today used a phrase "Human Capital" in a news headline, yesterday and today. Today I realized it was a good term to describe the "labor credits" that will be exchanged in this barter system, as opposed to traditional "capital" exchanged under traditional market systems, and also somewhat different from direct exchange of goods under ancient barter systems. NewEco will use a contract-bidding system based directly on labor-time as the standard unit of exchange, rather than using some arbitrary separate standard unit of exchange (as in market systems), or lacking any standard unit of exchange (as in ancient barter systems). I don't like the phrase "Human Capitalism" to describe my proposed system, because it's too likely to be misunderstood as a minor variant of current capitalism. Perhaps something like "Laboralism" would be a suitable new term, sounding vaguely like "Liberalism" but with a clearly different second letter "a" instead of "i" to give a clue this is something different in some day?

Minor clarification 2009.May.03 to answer misconceptions that some people have expressed: Marxian socialism/communism had the concept of "to each according to his need, from each according to his ability", directly applied to need for money/services and ability to do useful work. My system is very different. I apply Marx's idea only to getting a job, not to payment for work. Everyone is entitled to a job regardless of whether he/she is good or not good at getting jobs (convincing some stranger to hire the worker). Jobs are supplied by the system, automatically, per the worker bidding on contracts, requiring only the ability to navigate the bidding process and choose tasks which the bidder is likely to be able to perform. Pay for work is totally non-socialist. The worker gets paid only if the worker completes the contracted work adequately. Need for pay is irrelevant to my system, except insofar as nobody would bother to bid on a contract if they didn't feel that they needed (or desired) the pay which would result from completing the contract.

Update 2009.May.03: For the first time somebody asked a substantial question about NewEco. So rather than answer it directly I started a FAQ

Update 2010.Feb.19: While reading about a proposed economic system called "Natural Money", I first learned of an ancient Egyption grain-bank. NewEco is similar except that instead of people depositing corn or other grains they perform labor, and their receipts are expressed in labor time, and when they later withdraw their labor credits they get new services provided by the WebSite rather than their original grain/services back, and instead of being issued paper receipts they get a credit on their e-account. But still, these credits, essentially "funny money", can be traded to other people for their services.


.
Update 2010.Apr.24: From the start I had the idea that the NewEco main server would control satellite servers (running specialized services such as FilJob) by exchanging public-key signed+encrypted messages that encapsulate something like SOAP RPC and RMI.
A few weeks ago I figured out how I want to do billing for such satellite services, and I'm finally writing it up now:
  1. On main server (Portl1), user selects a service and parameters for a service request, is advised how many seconds of script-time this is likely to consume, and user confirms how much labor-credit to transfer from user's main account into escroll to pay for the satellite task.
  2. Main server moves that amount of credit from user's main account into an escroll record.
  3. Main server sends message to satellite, providing details of service request, and number of milliseconds of credit in escroll to cover the requested task.
  4. Satellite server breaks task into reasonable-sized chunks, deducting time consumed by each chunk, estimating time needed for next chunk, aborting the sequence whenever it is likely the *next* chunk would require more time than remains in escroll.
  5. If, despite estimation of time needed for the last chunk, it actually needs more funds than remain available, that last chunk is aborted at the earliest possible moment and all partial results from that chunk are discarded.
  6. Satellite server sends response back to main server, providing results from each chunk that was completed before funds ran out, and including a "receipt" for the overall funds transfer:
  7. Main server verifies consistent arithmetic (total = charge + refund), moves charge to designated satellite-owner account, returns refund to user's account, updates escroll record to show the transaction was completed, stores results in user's account, shows receipt and toplevel index of results to live user.
  8. User can now click on links from the index to browse the results.
Note that users trying a new satellite service for the first time probably don't yet trust it, so they would allocate only a very small amount of funds. This is inefficient, because the overhead in setting up the satellite process might be more than the cost of the service itself, but it's relatively safe, because not much is at risk. After a user gets to trust that a particular satellite service really is useful, and that the charge for service is reasonable, and also the user is more experienced at making good requests that will return good results, the user can allocate larger chunks of funds per transaction, so that the overhead is a relatively smaller portion of the charge, thus efficiency is greater.
.

To contact me: If one of the specific services listed above interests you, click on that link, pass the Turing test there, and then use the specific e-mail address there. Otherwise use my general contact page uh3t and click on "Contact me" and pass the generic Turing test there. Or post a public message for @CalRobert on Twitter.

.
.
.
.
.
.
.
.
.