> Today it’s the fashion to make web services in a very “lightweight” way, to offer minimally viable web products free, and to iterate rapidly as experience is gained with initial web users.
> I really envy people doing software with the web. One could do much better these days. But we didn’t have it, and so we were forced to do many things that wouldn’t be sensible today.
It's true there's a lot less cost and overhead to build and ship software today, but this is a double-edged sword: the perceived value of the software is also lower, and so people are less willing to pay and even expect the product to be free. I would argue it's much more difficult to build a software business these days because of this. If you can't sell your product, it's impossible to build a sustainable business.
I struggle with some of my ideas because of this. How do I compete in spaces where people can get applications for free due to ads, with a paid service with no ads.
HN would be the first place I'd comment about it yeah, I think my only option is to do something more directly profitable and subsidize the cost of a social media apparatus off of it.
I think this is happening with games, especially in the non triple A category. It is way easier to make games but the value of each game feels way lower to me now. This is multiplied by the fact that I can play thousands of games for free via emulation or flash carts for old systems.
Been doing engineering software since late 80's and this article hit me in the feels. I always wondered what the obsession with Harvard Graphics was in the early versions of PP. Now I understand.
Never had to ship software on 9-track tape, but remember receiving the source distro for C++ v1.0 from AT&T on one (cfront, no MI, etc)
Did ship plenty of software on QIC tape though, and man what a PITA. After much experience, we ended up retensioning every tape before writing. Sending releases to 100+ customers generated a Borg-cube of tapes that had to go into individual boxes for shipping, along with the rainbow of other tape flavors like TK50s and the various 4mm and 8mm tapes.
Documentation was a big deal, because once it was printed, you had a Borg-cube of shrink-wrapped paper and binders that were not going to change until the next release. I still miss proper documentation. Endless web pages are a lot more difficult to sit down and read start to finish.
This article helped me realize that I was shaped by this in the same way that many peoples grandparents were shaped by growing up in the great depression.
We built and shipped educational software to schools in the 80s and 90s; starting with homecomputers and pcs and later on (of course) only pcs. Good times sending stacks of disks off with the postal service. We also, starting late 80s (running on an msx2), had a BBS which was written by me so it had the licensing/logistics/accounting in there; barely anyone used it for getting their software, but we used it ourselves for mostly everything.
Good times; not having to worry about library versions/updates was nice actually. Besides turbo Pascal (later delphi), we had no 3rdparty dependencies up until we sold the company.
> We couldn’t reach potential customers directly (there was no web), so we had to groom editors of computer magazines and feed information to them, hoping they would print it in their magazines.
Editors of computer magazines were the "influencers" in the '80s.
this is true, but they also seemed to be deeply involved in the industries and products they promoted (or panned). It was much harder to start/run a magazine, and the market tiny compared to present; I can't help but believe it was more about the software than being the king maker. Stories abound of creators showing the editor their invention over the kitchen table. Today's influencers are hacks in comparison.
Interestingly, Ghostbusters (1984) was rewritten to have the team being a startup, because everyone was beginning to start up their own businesses at the time.
My company "Lindley Systems" did all this from 1980 (when I was 14) until the mid 90s, in the Heathkit (later Heath/Zenith) arena. I still have master diskettes and original manuals ready for taking to the Xerox shop, and only a few years ago tossed boxes full of registration cards (with 13 cent stamps on them).
We made the transition from Heathkit HDOS to CP/M and MS-DOS but never shipped a product for MS Windows. We almost had a product ready in 1996 but then MS "upgraded" VB 3 to VB 4 and we started a rewrite, almost completed just in time for the "upgrade" to VB 5 - by which time our market had moved on.
It was a fun time to build custom and specialized hardware and software.
> We made the transition from Heathkit HDOS to CP/M
A very unusual case of a company explicitly deprecating its own proprietary OS, and shifting to an external standard, on the same hardware. Tandy giving existing Model 16 customers Xenix and shipping it with new units is the only other case I can think of offhand.
IBM did give up on marketing OS/2 by the late 1990s (and the PC division arguably did so around the time Windows 95 came out), but I am not aware of IBM explicitly telling new and existing customers that Windows is the way forward for existing systems.
A slightly different way of answering your question is that sometime after the PS/2's launch, IBM began explicitly noting that its software and peripherals were compatible with non-IBM computers. PC DOS 5.0 might have been the first. <https://np.reddit.com/r/vintagecomputing/comments/1jleun5/ni...>
What a great read. I've lived all of my professional life (2014-) shipping productive code by just pushing to repos or specific branches. I avoid getting into mobile app development due to what a pain it is to get to the stores and stay compliant with ever-changing policies. I can't even imagine what was like delivering software in a cartridge or CD without a chance to update afterwards. It feels like such a titanic endeavor
It requires a different way of coding: bug-free is a serious target, as far as it can be approached. It is a permanent concern while coding, with a lot of testing, and releases are hard releases, not agile output. No titanic effort there, just being serious and focused with quality.
If your intent is ship-once working software, you write towards that goal. You use fewer dependencies, and they are all effectively version locked. It's like putting books in a box. You put them in the way you expect them to ship, rearrange as needed, and when they're all securely in, you ship.
The current update fast and furiously free for all is like trying to bundle a few dozen kittens in a bed sheet by comparison. Often with a bunch of random chaos monkeys you've never met "helping."
I remember playing a Commodore 64 game back then, maybe Pool of Radiance, and seeing a long list of play-testers in the credits. (And thinking what a cool job that would be.) They really had to put a piece of software through its paces back then before shipping it. And bugs still made it into the final copy, but if they did the job right, they were annoying or amusing bugs, not anything game-breaking.
> Today it’s the fashion to make web services in a very “lightweight” way, to offer minimally viable web products free, and to iterate rapidly as experience is gained with initial web users.
> I really envy people doing software with the web. One could do much better these days. But we didn’t have it, and so we were forced to do many things that wouldn’t be sensible today.
It's true there's a lot less cost and overhead to build and ship software today, but this is a double-edged sword: the perceived value of the software is also lower, and so people are less willing to pay and even expect the product to be free. I would argue it's much more difficult to build a software business these days because of this. If you can't sell your product, it's impossible to build a sustainable business.
> even expect the product to be free
I struggle with some of my ideas because of this. How do I compete in spaces where people can get applications for free due to ads, with a paid service with no ads.
If you find out, please let me know... :)
HN would be the first place I'd comment about it yeah, I think my only option is to do something more directly profitable and subsidize the cost of a social media apparatus off of it.
I think this is happening with games, especially in the non triple A category. It is way easier to make games but the value of each game feels way lower to me now. This is multiplied by the fact that I can play thousands of games for free via emulation or flash carts for old systems.
Been doing engineering software since late 80's and this article hit me in the feels. I always wondered what the obsession with Harvard Graphics was in the early versions of PP. Now I understand.
Never had to ship software on 9-track tape, but remember receiving the source distro for C++ v1.0 from AT&T on one (cfront, no MI, etc)
Did ship plenty of software on QIC tape though, and man what a PITA. After much experience, we ended up retensioning every tape before writing. Sending releases to 100+ customers generated a Borg-cube of tapes that had to go into individual boxes for shipping, along with the rainbow of other tape flavors like TK50s and the various 4mm and 8mm tapes.
Documentation was a big deal, because once it was printed, you had a Borg-cube of shrink-wrapped paper and binders that were not going to change until the next release. I still miss proper documentation. Endless web pages are a lot more difficult to sit down and read start to finish.
This article helped me realize that I was shaped by this in the same way that many peoples grandparents were shaped by growing up in the great depression.
We built and shipped educational software to schools in the 80s and 90s; starting with homecomputers and pcs and later on (of course) only pcs. Good times sending stacks of disks off with the postal service. We also, starting late 80s (running on an msx2), had a BBS which was written by me so it had the licensing/logistics/accounting in there; barely anyone used it for getting their software, but we used it ourselves for mostly everything.
Good times; not having to worry about library versions/updates was nice actually. Besides turbo Pascal (later delphi), we had no 3rdparty dependencies up until we sold the company.
> We couldn’t reach potential customers directly (there was no web), so we had to groom editors of computer magazines and feed information to them, hoping they would print it in their magazines.
Editors of computer magazines were the "influencers" in the '80s.
this is true, but they also seemed to be deeply involved in the industries and products they promoted (or panned). It was much harder to start/run a magazine, and the market tiny compared to present; I can't help but believe it was more about the software than being the king maker. Stories abound of creators showing the editor their invention over the kitchen table. Today's influencers are hacks in comparison.
Interestingly, Ghostbusters (1984) was rewritten to have the team being a startup, because everyone was beginning to start up their own businesses at the time.
My company "Lindley Systems" did all this from 1980 (when I was 14) until the mid 90s, in the Heathkit (later Heath/Zenith) arena. I still have master diskettes and original manuals ready for taking to the Xerox shop, and only a few years ago tossed boxes full of registration cards (with 13 cent stamps on them).
We made the transition from Heathkit HDOS to CP/M and MS-DOS but never shipped a product for MS Windows. We almost had a product ready in 1996 but then MS "upgraded" VB 3 to VB 4 and we started a rewrite, almost completed just in time for the "upgrade" to VB 5 - by which time our market had moved on.
It was a fun time to build custom and specialized hardware and software.
> We made the transition from Heathkit HDOS to CP/M
A very unusual case of a company explicitly deprecating its own proprietary OS, and shifting to an external standard, on the same hardware. Tandy giving existing Model 16 customers Xenix and shipping it with new units is the only other case I can think of offhand.
What do you think of this 1983 ACM paper comparing HDOS and CP/M? <http://delivery.acm.org/10.1145/360000/358070/p188-pechura.p...>
Did IBM do this with OS/2 as well?
IBM did give up on marketing OS/2 by the late 1990s (and the PC division arguably did so around the time Windows 95 came out), but I am not aware of IBM explicitly telling new and existing customers that Windows is the way forward for existing systems.
A slightly different way of answering your question is that sometime after the PS/2's launch, IBM began explicitly noting that its software and peripherals were compatible with non-IBM computers. PC DOS 5.0 might have been the first. <https://np.reddit.com/r/vintagecomputing/comments/1jleun5/ni...>
What a great read. I've lived all of my professional life (2014-) shipping productive code by just pushing to repos or specific branches. I avoid getting into mobile app development due to what a pain it is to get to the stores and stay compliant with ever-changing policies. I can't even imagine what was like delivering software in a cartridge or CD without a chance to update afterwards. It feels like such a titanic endeavor
It requires a different way of coding: bug-free is a serious target, as far as it can be approached. It is a permanent concern while coding, with a lot of testing, and releases are hard releases, not agile output. No titanic effort there, just being serious and focused with quality.
It was...easier?
If your intent is ship-once working software, you write towards that goal. You use fewer dependencies, and they are all effectively version locked. It's like putting books in a box. You put them in the way you expect them to ship, rearrange as needed, and when they're all securely in, you ship.
The current update fast and furiously free for all is like trying to bundle a few dozen kittens in a bed sheet by comparison. Often with a bunch of random chaos monkeys you've never met "helping."
I remember playing a Commodore 64 game back then, maybe Pool of Radiance, and seeing a long list of play-testers in the credits. (And thinking what a cool job that would be.) They really had to put a piece of software through its paces back then before shipping it. And bugs still made it into the final copy, but if they did the job right, they were annoying or amusing bugs, not anything game-breaking.
https://news.ycombinator.com/item?id=44013046