| new3 |
| faq |
| tutorial |
| tiny |
back to:
When the project was started, there was simply no choice: a PC with 256K of RAM and floppies was US$3000 back then in the United States, several times that in Brazil ( thanks mostly to the "reserved market" policy ). Today, with cheap motherboards flowing in from Taiwan it would seem a good idea to simply sell Merlin as a set of disks to be installed in any PC. The start up costs of a software company are also far less than those of a hardware manufacturer.
The reason why the Merlin project still includes hardware is that it is designed for computer novices. An integrated solution is Apple's main selling point today. In many environments the end user must install and maintain their computers without expert help.
It has often been pointed out that a software-only Merlin would lower the cost of trying it out. This, however, also has its down side: it also lowers the cost of giving up - people are more prone to abandon OS/2 than the Amiga, for example ( yes - I know Commodore's fate and NeXT's situation ). Besides, it is only cheaper if someone already has the necessary hardware, but in that case they already have a software system that is meeting ( at least partially ) their needs. So this solution is most attractive to people who are unlikely to be Merlin customers. On the other hand, these "experts" are probably the ones who will advise the novices on their purchases and future Merlin programmers will most likely come from their ranks. So a 386 port of the system is planned.
It is interesting to note that the question novices
ask first about the project is "have you patented it
yet?". They rarely have a clear notion about what
software is and find it quite natural that a new
computer is to be sold.
While I like to use different languages for different tasks,
Merlin was designed to be easily learned. This meant that a
single language for all uses would
be better. The language would have to be simple but extensible.
It would also have to be very dynamic to cope with some of
the requirements of the system.
Just a few years ago the low level code would not have been
possible in a pure object oriented language like Self, but
the Self group has
developed advances in compiler technology which have made
this option practical.
I think that software should be protected by Copyright, not
patents.
The hardware designs were never patented either. While they
have included some original ideas, it would surprise most
people to know how little uniqueness there is even in
designs "on a clean slate" like Merlin. The age of "chip-sets"
has made computer design patents even less likely.
The revenue from Merlin will come from a new system called
"superdistribution" ( see articles
by Brad Cox for more details ).
The basic idea is that charging for each use, rather than for each copy,
better matches the characteristics of software products.
The objects might be distributed via the internet, on a free ( or
cheap ) CD-ROM in a magazine, given away by a friend or any other
conceivable way.
The scheduler
in the Merlin system will monitor the use of each object and create
an encrypted "software bill". The user then connects to a payment
agency every month ( or two months ) and the corresponding value is
charged to his credit card. An encrypted "receipt" is loaded into
the user's system and some objects might choose to check for its
presence before executing.
A central payment agency will eliminate most of the problems that
shareware programs face ( problems which would be much worse in
the case of superdistribution of nothing were done to solve them ).
Many people fail to pay for shareware because it is terribly
inconvenient and not because they are dishonest. Sending off three
five dollar checks is more bother than most people are willing to
put up with. If the authors are from a different country, things
become much worse. The banks in Brazil charge 70 dollars to send
any amount to South Africa, for example ( mailing money is illegal
in both countries ). With a central agency the users can easily
make a single payment and authors can receive a single check each
month corresponding to thousands of users all over the world ( minus
a small service charge for the agency, of course ). There might be
several competing agencies, which would then collaborate with each
other so the users could pay through any of them and the authors
could register with any other.
It is important to note that we have talked about the payment
for the use of "objects", not "programs". These objects might
be a text editor or a game, but they might also be a new font,
a drawing, a text describing a rare species of fish, and so on.
The only totally secure system would be to include special
accounting hardware inside the CPU itself. Other hardware solutions,
like that used in the superdistribution project, make breaking
the system much harder, but not impossible. A software-only system
is easier to defeat, but also much more convenient for the users.
Given that many people will depend on the proper function of the
accounting software in Merlin for the income, a solution called
"continuous upgrade" was developed based on the ideas that:
The real economic damage comes from the second group making their
hacking available to part of the first group. With the continuous
upgrade system, every time the users pay their monthly
software bill they also automatically upgrade the accounting
software to a new version. New objects (or upgraded versions)
distributed in the net will only be compatible with recent versions
of the accounting software, and will simply not work on a machine
that has an old hacked system.
Pirates would have to break a new version of the system each month,
and then distribute this a others. This can't be done without
risking detection, so is not very likely. This guarantees that
the loss to authors due to illegal free use of their objects will
be limited to some small fraction.
It is not surprising that such an ambitious project is taking so long,
given the limited resources. Things should get much better when
Merlin is commercially available, which should "bootstrap" the
project financially.
While in the current phase of development there is little you can
do to help except to send suggestions, the system is being designed
to be as open as possible. On the first release of Merlin,
( scheduled for late January, 1996 ) a beta testing program will be
initiated and the more people that participate, the better.
With its reflective architecture, it will be very easy to replace
any component. So not only will the development of applications
for Merlin be welcome, but also alternate networking software,
multimedia system, persistent stores and anything at all! Due to
the revenue system adopted ( see selling Merlin )
the components developed by me will not be privileged in any way.
This is the opposite of the Microsoft way where more and more parts
are built-in to Windows making any user interested in third party
solutions actually pay twice.
No one becomes a Master Magician without some studying. The idea in
Merlin it to eliminate useless learning, of which there is a vast
amount in today's computers. How does learning the difference between
XMS and EMS memory help users in their daily tasks? It doesn't - it
is only a silly obstacle in the path of more important things. But
there are many things that must be learned to accomplish tasks that
were impossible without a computer. Suppose you want to find out
how to automatically color code your mail according to the sender -
that requires useful learning.
People used to say that in the future computers would be as easy
to use as the telephone. But just try to install a phone with
fax and voice mail and you will see that a no-training system
is not here yet...
Training tools will be developed for Merlin ( see
the tutorial ), however, so it should be possible for a novice
to use the system itself to learn how to make the most of the system.
| faq |
| tutorial |
| tiny |