Today we take the concept of a centralized software repository for granted. Whether it’s apt or the App Store, pretty much every device we use today has a way to pull applications in without the user manually having to search for them on the wilds of the Internet. Not only is this more convenient for the end user, but at least in theory, more secure since you won’t be pulling binaries off of some random website.
But centralized software distribution doesn’t just benefit the user, it can help developers as well. As platforms like Steam have shown, once you lower the bar to the point that all you need to get your software on the marketplace is a good idea, smaller developers get a chance to shine. You don’t need to find a publisher or pay out of pocket to have a bunch of discs pressed, just put your game or program out there and see what happens. Markus “Notch” Persson saw his hobby project Minecraft turn into one of the biggest entertainment franchises in decades, but one has to wonder if it would have ever gotten released commercially if he first had to convince a publisher that somebody would want to play a game about digging holes.
In the days before digital distribution was practical, things were even worse. If you wanted to sell your game or program, it needed to be advertised somewhere, needed to be put on physical media, and it needed to get shipped out to the customer. All this took capital that would easily be beyond many independent developers, to say nothing of single individuals.
But at the recent Vintage Computer Festival East, [Allan Bushman] showed off relics from a little known chapter of early home computing: the Atari Program Exchange (APX). In a wholly unique approach to software distribution at the time, individuals were given a platform by which their software would be advertised and sold to owners of 8-bit machines such as the Atari 400/800 and later XL series computers. In the early days, when the line between computer user and computer programmer was especially blurry, the APX let anyone with the skill turn their ideas into profit.
The Fine Print
Of course, Atari’s goals with the program weren’t completely altruistic. At the time, the Atari badly needed more software. So badly that they were willing to take on the role of publisher themselves to help ease the burden of getting new software out for the platform. Developer Chris Crawford, who’s war simulation Eastern Front (1941) ended up selling over 60,000 copies through APX, recalls the origins of the program:
The guy who cooked up the idea, Dale Yocum, was trying to explain to the management that there are a lot people out there that like to write programs and if we can publish these programs for them, it’s a win-win. He put together a business plan for it and said ‘Look, we only need a little bit of money and this thing can be self-sufficient and it might make some money.’ They grudgingly agreed to let him do it because the Atari platform desperately needed a larger software base, a void not being filled by the other publishers of the day.
Costs of the program were reduced by using very utilitarian packaging for the software, and having the developers themselves write the manuals. All Atari had to do was run off the copies and mail them out. Even the split was heavily in Atari’s favor: the developers only received 10% of the sale price for each unit sold.
So not only did APX help fill a gap in Atari’s software library, it brought in plenty of money for them as well. Consider that Eastern Front (1941) is listed at $29.95 in the APX catalog, which totals to nearly $1.8 million (approximately $4.5 million, today) dollars in sales for that single game alone.
The APX Archive
While [Allan] did bring along an Atari 800XL to demonstrate some of the software distributed via APX, the real draw of his table was a selection of mint condition APX boxes, tapes, manuals, and catalogs. The sparse box art and utilitarian manuals were a stark reminder of the program’s frugality. Some of the manuals had all the frivolity of a high school book report; something which was immediately noticeable at VCF East, where there was no shortage of contemporary software to compare against.
[Allan] has made it his mission to scan the boxes and manuals for all of the APX software he can find, including the APX catalogs themselves, and make the information publicly available on the AtariWiki. So even if you can’t see his impressive collection in person, the data about this fascinating experiment in software distribution won’t be lost to time.
History Repeats
Perhaps the most interesting aspect of this look at APX was hearing about its parallels with modern software marketplaces. Some of the programs released via APX were hyper specialized, such as an application for keeping track of a newspaper route and one that was used to calibrate color TVs. These programs would likely never have seen the light of day, at least commercially, if a marketplace such as APX didn’t exist.
But as APX became more popular, Atari had to start tightening up their standards. In the early days, the bar was fairly low for acceptance into the program, but towards the end more and more software had to get rejected. While there’s no hard numbers on how many programs got the boot, Director of APX Fred Thorlin did admit in an interview that some of the early titles would never have been accepted if they were submitted later on in the program.
So the next time you look at all the low effort copycat games and applications vying for your download on the Google Play store of Apple App Store, just remember: Atari tried to warn us.
“Some of the manuals had all the frivolity of a high school book report; something which was immediately noticeable at VCF East, where there was no shortage of contemporary software to compare against.”
Even back then no one wanted to do documentation. Still don’t.
Back in the 90’s I was working on an IBM project. They had the good sense to outsource all documentation to a third party. Yes, that was way more expensive but it kept the code monkeys happy. Nobody wants to do documentation.
Literate programming.
It would be a shame not to point out that [Kevin Savetz] of Antic: The Atari 8-bit Podcast have published interviews with over half of the people who wrote software published by APX. Some of them are terrific and some have even led to source code being published.
Check out https://ataripodcast.libsyn.com/
Are programs today not “hyper specialized”? Maybe you really mean they had a small target audience, but that was the case with a lot of software back then. There weren’t that many mass-market packages other than spreadsheets, word processors, and Print Shop (and there were a LOT of spreadsheets and word processors).
I would argue that it’s a combination of two factors that results in hyper specialization here: you’re targeting a specific family of home computers (in this case Atari 8-bit machines), and within that user base providing software for a specific task. All of this within an era when everything is a unitasker — no multitasking operating systems in wide spread use yet to share the data between programs, so you’re stuck doing one task so you might as well do it properly.
>but one has to wonder if it would have ever gotten released commercially if he first had to convince a publisher that somebody would want to play a game about digging holes.
you mean like Dig Dug, The Pit, or Boulder Dash?
Probably ET. Although that was more about falling into holes than digging them, I think?
Falling into holes, or being dumped in a landfill?
B^)
Those games aren’t really ABOUT digging holes though, digging is just a play mechanic used to score/progress/whatever.
In the early versions of Minecraft, literally all you did was dig holes and stack blocks of material. There was no other goal, no scoring system, etc. It was a first-person digging simulator, entertaining only for those with the imagination to build stuff within it. The more traditional game concepts like enemies to fight and boss areas to reach weren’t added until later.
So it’s kind of like Dig Dug if you removed all the enemies, and the only thing you could do in the game was draw shapes with the tunnels.
Minecraft was not released on Steam or any other central app repository. Notch is sort of an anomaly. Now Flappy Bird, that is a great example
Great article…sure takes me back. When we started APX it really was quite special, as much a way to build community for the Atari 400/800 as anything else. As you say, making money was way down the list of priorities. We were trying to do everything we could to reduce the friction of getting new titles out for the new computer.
In the beginning we didn’t even bother with formal accounting. When cash, checks or credit cards would come in, we’d just store them up in a literal shoebox until it got full and then I’d take it down to the bank. I wrote the entire operation’s order processing system in BASIC on a maxed-out Atari 800!
We duplicated everything in house with a huge bank of consumer stereo cassette decks and a big bank of Atari 800 disk drives running on another Atari 800 running custom software I wrote. We’d keep just a few copies of a program on hand duplicating new copies as needed.
One correction, while we did ask authors to write a first draft of a manual, our lone tech writer, Ann Kelsey, would often have to rewrite them massively. She was incredibly quick at this, sometimes cranking out a manual a day listening to heavy metal.
Did you have any custom hardware on the go?
This is why I read the Hackaday comments section. OK, well, and it’s my job.
But this!!!
How about decentralised software repositories, but a few centralised software directories, with each record in them given a trust rating?
Centralized repositories have become a way for a tiny number of companies to control the software market and rake in huge amounts of money from software that others create, while sometimes allowing software that can “spy” on you. I think the time has come to introduce decentralized software distribution mechanisms with much better ways to provide trust to ensure that the software doesn’t contain viruses etc. Getting software from an App Store doesn’t prevent the inclusion of functionality that you probably wouldn’t want if you knew about it or had a choice. Consumers should be able to choose who they trust to verify their software. Blockchain isn’t the answer as software verification requires expertise and verifiable trust, so an anonymous system won’t work. The solution is probably something like an unalterable public ledger with verified participants. That also lets you get rid of the onerous proof of work/ proof of stake requirements of most current block chain systems.