TRS-80 Fragmentation

[Tapley, Mark]

> On Apr 27, 2018, at 9:08 AM, Geoffrey Oltmans via cctalk <cctalk at classiccmp.org> wrote:
> 
> Don't get me wrong. Like you I learned a lot due to all the variety of
> differing machines that were available in the market early on. From a
> business perspective I don't think it made a lot of sense however to have
> so many internally competing models.
> 
> Of course then, I guess you could argue that Atari probably had the most
> cohesive set of computers, but that didn't necessarily translate to great
> success. I guess that did mostly work for Apple with the II line, save for
> the major III distraction.

	This is actually a pretty interesting topic, and relevant both to decision-making today and to classic computers. How did, and how should have, companies select architectures (CPU families, bus structures, peripheral strategies, etc.) to ensure continued viability? Some examples I see and my simple-minded scorecard below. I’m trying to stick with hardware vendors, so I left Microsoft and NeXT (possibly unjustly) off the list, but in some cases (Tandy? TI? Digital Group?) I think the imbalance between hardware development and software development was a huge factor in the company’s success or lack thereof.
	Comments or corrections most welcome!

Digital Group: support 3 (?) different processor families on the same bus architecture (sort of)
	technically very impressive, but flexibility -> cost -> low market share; not long-term successful

DEC: support almost every available CPU, and invent some of your own besides.
	since supported everything, had price/performance dominance in most categories, but let *one* category slip away - business desktops - where much of the money was. Successful for a long time, but development costs overtook revenue eventually.

Apple: support one CPU, switching product line to another CPU as needed.
	Able to pick architectures to create new markets; limited interoperability but able to survive on single-market dominance (hobbyists, then education, then graphic design, then PDA’s…)

Tandy: Support every architecture, often 2 at a time in the same box:
	Mixed record, some winners and some losers; Software development often lagging sorely behind hardware, ultimately not successful.

TI: Single-architecture, lock-in software ecosystem
	Substantial money-loser even with potentially world-beating hardware (CPU); software achilles heel along with architecture bottlenecks on performance.

others?

	There are many complicating factors, of course. E.g. embedded systems have very different requirements from CAD workstations. Should a company maintain different architectures to support both, and how compatible should they be? 
	It looks to me like really strong support for outside developers is key for hardware providers, whether that is in the form of a cheap and effective development toolkit and good developer’s forum or a completely open architecture.
										- Mark