Applications that make money
Posted 29 Oct 2001 at 17:26 UTC by niksilver
We've just launched
under the LGPL and are looking for input from
Advogato people. Jtrix allows you to write apps that grow and shrink and
move around to find the
best places to live, and so never cost more to run than necessary.
Is this of value to you?
brief intro doc,
the latest downloads
and more papers on the
home page. But in brief:
- Jtrix applications can find their own hosting and services, and
is accounted, so they never use more than they need and can always
be billed precisely. No more spending
hundreds of thousands of dollars on a redundant server farm three months
before you hope it will be needed.
- A good example would be the problems of
SourceForge, mentioned recently on these
pages. If we had this in Jtrix then the more popular projects would be
directly supported by micropayments, while the less popular ones
down and not need to spend as much.
- The success of Jtrix depends on being widely accepted which is why
released it under the LGPL.
- We need developers from the open source community in order to prove
So what do you think of Jtrix? Do you have a need for it? Would you
joining us as a contributor? Please let us know.
Which Java VM?, posted 30 Oct 2001 at 02:09 UTC by Qbert »
I'm a little behind the times when it comes to Java; I haven't written
anything in Java since late 1999. At the time, all the Java VMs for
Linux sucked very badly. Kaffe was
unstable and out of date relative to Sun's ever-changing suite of
libraries; Japhar didn't seem to
be actively maintained; Sun's VM was unstable, prohibited modification
and redistribution, and was supported only as a buggy port maintained
by Blackdown (which free
service Sun nearly lost when it presented the Blackdown port as if
it were its own work, even after backing down and apologizing).
IBM's jikes was a very fast
compiler, but without a decent VM to run its output it was useless. I
gave up in disgust.
So, I'm hoping someone has solved these problems since I turned my back
Java. What do you think? What is the most stable VM for Linux? The
fastest? (Is there a decent JIT for Linux yet?) The most complete in
terms of tracking Sun's library APIs? If you tested your code on
Linux, which VM did you use? Is there a clear choice, or are there
different VMs that fulfill these criteria? Is any of these free
I liked Java as an object-oriented language, but I couldn't stand the
implementation. I'm not likely to use any Java project till it shows
good performance and stability on Linux, on a free VM.
Unless you actually mean that 5 cents will translate into some fixed
amount of some definable computing resource in the system, avoid at all
costs the use of the term "micropayment."
People/users get very weird as soon as they're told that some number on
a computer might be viewed as actual money. We had this problem with
Mojo Nation in that our "micropayment" system was much
better described as an internal barter system for computer resources.
M*cropayments, posted 30 Oct 2001 at 09:00 UTC by niksilver »
Hi Splork, thanks for the reply. We certainly looked at
MojoNation and it has some good ideas.
The idea is to buy real things such as CPU, disk, etc,
well as mail accounts, database space, and any other service you can
If this can be done efficiently enough then you know what you're
your money on as you spend it.
Perhaps "micropayments" isn't a good word
to use. But people who spend thousands of dollars on a Web site (and
those who spend $200/year on their own personal home page) know that
resources cost money, and if they need more then they can spend more,
if they need less then they shouldn't have to pay as much. If that's
called "micropayments" or just "not much money" it's still the same
thing in practice. Either way, it's important that you shouldn't have to
spend thousands of dollars in advance - that creates a trading
gap, it means risk and/or borrowing large amounts of money and/or
selling a share of your company/project to other people to hold you over
until that up-front investment pays off.
M*cropayments, posted 30 Oct 2001 at 16:59 UTC by uleonhardt »
IMHO, the real point of a micropayment would be to pay for
a one-off interaction with an unknown party. For example,
a directory lookup could conceivably be paid for by a
micropayment. Then, one could create a directory service
and make money buy charging for lookups.
Technically, it seems quite possible to have a pervasive
infrastructure enabling efficient micropayments.
Is this realistic?
As the previous poster pointed out, people are not very
comfortable with micropayments, at least on the
Internet. On the other hand, few people seem to mind services
being charged to their telephone bill. So isn't it just a
question of the user's mindset? I think it is going to be
a slow process, but eventually most people will learn
to pay for most services on the Internet.
This may not seem like a good thing, but it would enable
better/more sustainable business models than seen during the
last Internet bubble.
Qbert: I wrote this diary entry a couple of weeks back about the big difference between the exciting, dynamic world of open source Java application development, and the relatively bad state of open source Java infrastructure.
It's much better now than in 1999, though. Blackdown's JVM is stable, if not lighting fast, and there is promising work appearing, especially the support for native code compilation of Java in gcc-3.0, and the support by HP of open source Java (I'm thinking of their big cntribution to the Mauve project). What is desperately needed is a decent open source implementation of J2EE, and what would be very helpful is an open source reimplementation of Swing. People are working towards the former, but there looks to be little chance of Sun certification, and nobody is doing serious work on the latter.
: running a micropayment infrastructure to
cover tiny transaction costs is less useful than it may seem. To use
your directory lookup example, the micropayment resource overhead is
much larger than the lookup itself.
Here are some issues with micropayments (and some notes on what we did
- The cost of performing an accountable transaction between two
parties is much higher than most people ever assume. (hosting, cpu,
redundancy, backups, security and administration of payment authorities
costs a lot). If your payment system is exchangable for real money in
any way, you need lawyers and financial gurus to pay attention to the
loads of required work for being a financial institution. This can not
be done openly, a corporation or government will need to be involved if
actual finances come into play. (amusing note: The Principality Of Sealand is both)
- You need to determine what the smallest unit of work/resources
worthy of incurring the actual overhead of a real payment transaction is.
In mojonation we used a microcredit system, using a real payment only
when the credit balance was large enough to warrant the overhead. Ours
defaulted to extending credit without any prepayment to keep the
overhead low on transactions between previously unknown parties.
However, this is vulnerable to attack by distributing queries among
redundant parties and to parties who change their identity frequently.
To prevent this, one could require a prepayment with unknown parties so
that instead of on credit work is performed from a prepayed tab. Then
the problem changes to be that new parties may appear, take a
prepayment, then disappear (including reappearing as a different party
to collect more prepayments). Note that prepayment is more like a
subscription system, just finer grained.
- Determining the microcost of a resource is difficult if not impossible.
We chose paris metro pricing in mojonation. How much a party charges is
solely determined by the offers it has received at that instant as well
as its current resource usage load (cpu, bandwidth, etc). This means
service will cost 0 (or some other configurable minimum to cover fixed
overhead) much of the time. Parties who offered higher payments have
their requests served first. Also important is that it prevents the
need for any price setting/advertising/publishing/negotiating which
would otherwise complicate a system by adding significant extra message
and latency overhead. The advantage of using 0 as the minimum cost is
that parties in the system who choose not to pay aren't screwed, they'll
just get the worst class of service.
- How will denial of service (DOS) attacks effect the system. If the
payment authority is taken offline or significantly overloaded do things
still work? Do some parties gain and others lose (thus providing
financial incentive for launching a DOS attack)?
This was another reason behind the default behavior of extending credit
without a prepayment in mojonation. That way everything doesn't stop when
the payment authority is being nuked. Unfortunately it could be abused
(and no doubt would be if mojo were exchangable for real money)
- Consider the impact of taking a service that is free and requiring
micropayments for it. How would sourceforge support itself in your
example when many of its users are not willing to pay anything and would
seek other philanthropic project hosting locations or put up with less
reliable but free home dsl line hosting?
Consider the impact of taking a service that is free and requiring
micropayments for it.
What if thouse m*cropayments whould be not for service , but for
It could be turning off banner ads, or requirment for better QoS (same
as with CPU)
BTW. what whould be with web-searchers crawlers? Need Google pay you
for indexing your site? :)))
There is one service... Fileplanet or something like that (found link on
make a month subscription for geting free demo versions
of games, posters etc.
raised some interesting and valid concerns
about the practical feasibility of micropayments. I think micropayments
are a hard problem. (Or perhaps it is difficult because we try to
replicate the off-line world in cyberspace, inappropriately ?)
IMHO, MojoNation had a pretty sophisticated infrastructure for making
small payments efficient by batching them up.
Let me respond to the points raised:
- Interface to the real world. At the moment, we follow the
approach that we have (possibly several) on-line banks that are
self-financing. As soon as the on-line currency will become convertible
into real money, those on-line banks will also have to become proper
banks in the real world. That's the easy bit. Then we get taxation
issues. By default, the government-imposed system for collecting
value-added tax would have to be extended into cyberspace. That would
be a real pain! Perhaps some kind of exemption could be granted. Then
there is the issue of controlling the money supply within cyberspace.
Presumably we there should be some inflation in order to make people
spend their money. I guess with have to take one step at a time.
- Cost of payment transaction. I think classical micropayments
(one-off interaction with unknown party) are only efficient if the
payee can verify the payment (to some degree) without contacting a
third party. The challenge is to make cheating more expensive than
paying up. However, there needs to be some fairly smart "immune-system"
in the background that weeds out persistent cheats. And that's the
difficult part. On the other hand, if the micropayments can be batched
up (eg. a subscription-type scenario) things become easier - except
that one side has to take a risk (as pointed out in the previous post).
I think that can't be avoided - again this leads to the need for a
- Pricing resources. Our approach is top-down, ie. we calculate
what it takes to run the machine, depreciation of hardware, etc.
This leads to prices of basic resources (CPU, disk, memory). Services
would be priced to cover the cost of the necessary resources, plus a
bit on top for profit.
- Financial incentives for DOS. Never thought about this one. Call
the police, I guess.
- Starting to charge for a previously free service. Very difficult.
That's why its important to have the financial infrastructure in place
from the very beginning.
quick note: it sounds like you're pondering inflation to prevent
hoarding. That's one approach but may not be necessary. With many
forms of digital currency (such as signed digital tokens), each coin can
be given a life time such that it must be cleared through the central
authority by a certain date or it becomes useless.
IMHO virtual money (I wouldn't call it m*cropayment)
can work only, if it works at technical,
social, philosophical and legal level at the same time.
We are definately not there yet.
Instead of a longer reply here, I decided to
game to illustrated my view.
Sorry for replying to my own post. Clever me,
all links needed authentication! :-( Here with fixed port number:
Instead of a longer reply here, I decided to
game to illustrated my view.
you would do well to examine the "millenium" project on
www.research.microsoft.com. basically it was a distributed OS that
allowed programs and resources to move and/or duplicate up to where the
demands were being made on the network.
i.e. if a site on the end of an ISDN line suddently became slashdotted,
it would automagically be duplicated up to a line with a big fat pipe,
for 15 minutes, until the demand went away.