Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!oliveb!Glacier!decwrl!sun!chuq
From: chuq@sun.uucp (Chuq Von Rospach)
Newsgroups: net.micro.mac
Subject: net.sources.mac and shareware (problems and solutions)
Message-ID: <2998@sun.uucp>
Date: Tue, 12-Nov-85 18:40:49 EST
Article-I.D.: sun.2998
Posted: Tue Nov 12 18:40:49 1985
Date-Received: Thu, 14-Nov-85 08:19:15 EST
Distribution: net
Organization: Sun Micro -- NFS Consulting Group
Lines: 87

[If you like this bugeater line, please send $5.00 to...]

The furor over net.sources.mac has me thinking. I was one of the people involved
in getting net.sources.mac started, and I've gotten a LOT of useful stuff in it
over the last year. At the same time I'm not satisfied with the kind of postings
I've seen in the last few months. In trying to figure out why I think I've found
two problems with net.sources.mac that we need to look at and resolve:
 
				 Lack of Source

There are historical reasons why there isn't much source.  Early on we were all
trying to make the machines work and there simply wasn't a good development
environment for the Mac. The only way to allow people to use things was to pass
a binary. Now, there is the compatibility problem. There simply isn't a
development environment dominant enough that "everybody" will have it (unlike,
for example, Unix [C] or Apple II [Basic]). Mac C doesn't talk to megamax or
sumacc, and there is pascal, lisp, forth, and various assemblers.

I've come to the conclusion that the compatibility issue is a red herring. We
post binaries because we've always posted binaries, and "compatibility" is a
good excuse. What I think we really need is solid examples of how to make the
achine roll over.  You can read Inside Mac for weeks and learn more from SKEL
in a few hours when it comes to the practicality of working with the machine.
Binaries don't teach you how to program the beast and, more importantly, don't
allow you to change the program to do what you want. Resources notwithstanding,
you can't hack a binary. You also can't learn from it.

It is time to bite the bullet and start posting sources again. I may not be able
to compile it, but if it is something I really want, I'll either convert it (and
learn in the process) or buy the system that CAN compile it. Binaries are handy.
Sources are useful, and it is time to make sources.mac useful as the teaching
tool it should be so we can all learn how to make better tools.

			    The Shareware Problem

In trying to decide what to do about the "shareware crisis" on the net, I went
looking through my archives. I found a LOT of "shareware" programs in it. The
number of "shareware" programs I have that I paid for turns out to be nil. In
trying to reconcile this position, I did some research into what "shareware"
should be."Shareware" (or "freeware") was a term coined by the late Andrew
Flugelman for programs he wrote for the IBM-PC called PC-TALK and PC-WRITE. He 
wanted to stay away from the normal distribution channels -- 40% for the
distributor, advertising, and the normal administrative overhead involved in
getting code to market.

His basic philosophy was that shareware was commercial quality code. If you look
at what his view of shareware is versus what is being posted as shareware, there
is a BIG discrepancy. He distributed a word-processor and a telcom program. We
are posting things like Binhex, disk initializers, and other toys. Is the stuff
being posted as shareware something that could have been sold in a store? 

With very few exceptions, no. Most of the stuff being posted as shareware would
have been written anyway, and in the old days given away at user group meetings.
Now, chasing the almighty dollar, people who might have shared their discoveries
about the machine are locking them away in undecipherable binaries in hope of
earning a few dollars. I can think of only two things I've seen pop by that I
felt deserved the "shareware" label. One is "Red Ryder" and the other is the
"Dungeons of Doom" game. Both of these are non-trivial programs with a lot of
work and finishing put into them, and both of them could easily stand on their
own in the commercial market. 

				What Do We Do?

The people posting "shareware" should seriously consider whether or not their
program deserves to be shareware. I think we all stand to gain a LOT more from
examining and discussing each others code than we could ever gain from passing
around binaries. The prime question would have to be "Is this something I'd want
to sell in a computer store?" and if you don't think the code is quite robust
enough or the documentation quite clear enough, the answer is no. If you aren't
sure, post the sources as shareware and let us pay you for the algorithm. We
need to pressure the off-net people to reconsider their positions, too -- 
shareware gives a few people some short term gains, but gives the Mac community
long term losses because we simply aren't sharing our knowledge with each other.
If I show you what I know, and you show me what you know, we both get better at
programming the machine, which is what it is all about.

Isn't it?

Anyway, Shareware has its place on the net, and it always will. But we should be
a lot more careful defining what is and isn't shareware and start posting the
sources that we will need to make everyone a better Mac programmer. It's time to
stop posting binaries, folks -- we simply don't need them anymore.
-- 
:From the Crystal Caves of Avalon:   Chuq Von Rospach 
sun!chuq@decwrl.DEC.COM                 {hplabs,ihnp4,nsc,pyramid}!sun!chuq

Our time is past -- it is a time for men, not of magic.