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.