Maintenance, addition of new functionality, bugfixing, porting to other platforms etc. takes easily 10x-50x time than the initial release, and eats the vast majority of the developers' time and energy.
This is where "not being paid for your work" translates into abandoned projects.
In the case of Apple, keep selling new hardware. I can't remember if they ever sold their software in the first years of Macs or if it was bundled with the hardware.
In the early OSX era they used to sell their office suite separately. Eventually it got bundled with hardware for free. They still sell some software, like Final Cut Pro.
For most software that can be sold in a box, without an attached cloud service, this approach works.
EDIT: Also some fraction would be using them on computers that literally haven't been upgraded or connected to the internet for a decade or more.
Even if they don't work on maintaining Office 2003 directly, they indirectly work very hard making sure every subsequent version of Windows does not break Office 2003.
It's backward compatibility if Word 2003 runs on the later Windows versions - like Windows 10 and 11. I don't know the answer to that, but I'm sure someone here does.
Though it's possible to mix and match so the OS backwards compatibility isn't the full story.
i.e. a launch copy of Word 2003 works on later OS updates, yet the final patch version of Word 2003 also works on a 2009 launch copy of 7.
If you don't understand Excel's history, it's better to not make such a bizarre claim.
What part of my claim is bizarre? My claim is simply that Word and Excel had 20 years of history prior to the 2003 release. Your claim that it was originally written on a different OS is not really a reasonable counter-argument. The Windows version of Excel came out 2 years after the Mac version, so that only knocks the history of the "Windows" version down to 16 years.
And that those were in turn based on the ideas of Von Neuman & co. from 1945 of tabulating numbers efficiently, and so on and so forth in roughly equivalent leaps all the way back to the first abacus.
It's so reductive of a perspective that it's self-defeating, since no human being, including you, could ever actually comprehend the entirety of technological development, or even just the post-1945 developments.
I think it is a pretty clear line between attributing the quality of a piece of software to two decades of prior development at the same company, with its own continuity of developers and institutional knowledge, as opposed to the general benefits all software gains from the industry advances it builds upon.
Not receiving new features is VERY different from not receiving maintenance. It is wholly implausible to believe that there has been zero energy spent on keeping those codebases working in the past 10 years.
This is in fact how all software worked until, I don't know, about two decades ago? Things being patched was a big deal, a voluntary manual process, and didn't happen often. The update would even have a well-known name like "Service Pack 2".
The idea that all software must be constantly maintained is recent and the assumption that it is necessary is mostly self-imposed by the software business. Users don't share this assumption, and in fact on many products, updates are viewed mostly neutral to negatively, other than perhaps critical security updates on products that are used in connection to the internet or untrusted data.
You don't have to believe me, I imagine practically every reader on HN has the means to verify this for themselves.
https://www.cvedetails.com/vulnerability-list.php?vendor_id=...
So you can try it out but don't open any documents, or run it while connected to the net. You'd better also not insert any images. Have fun!
We could also have a post "World where bad people don't try to break your software"
> Plenty of people are using Word, Powerpoint, and Excel 2003 just fine
Are you claiming that a reasonable majority (for the sake of discussion) of this plenty of people are using Office 2003 on Windows XP machines??
I'd doubt it. More like there's plenty of people using old software in modern versions of Windows. The maintenance work, of course, exists and has been done indirectly, by Microsoft, in the development iterations of Windows itself.
Whether or not they make up the numerical majority of all extant users is simply irrelevant to the point of 'Plenty of people'. It's easily many, many, thousands.
Office 2016 is going EOL in two years.
That's from Microsoft themselves. They do not hide these facts or make it hard to find.
I find it mindboggling that a simple program like text processors have to be continually updated for decades. Just program it right once for god sakes.
Unless they're also using computers and OSes from 2003 (spoiler -- they're not because those OSes wouldn't work with today's internet), those people are benefiting from untold efforts in the meantime to maintain their OS so it has that compatibility with 20 year old user space code.
That sweet sensation of being owner of what you paid for comes as a bonus.
Nowadays, software is different from the CD era, where you bought a game/software and that was it. Nowadays, people expect the software to be maintained, kept up to date and always compatible with the latest changes (new OS versions, compatibility with other software, etc.).
Maintenance is the high cost of software, not building it. This is why I sell my products with a perpetual license but with paid yearly updates. I can not work for free indefinitely as all the "lifetime" licenses promise.
First, some of these problems are created by software developers themselves. In particular, shoving in an online component where one doesn't need to exist basically guarantees that you will have recurring costs and the need for constant maintenance.
Second, Microsoft is much more careful about maintaining backwards compatibility than Apple. I can generally fire up 10+ year old software on Windows 10, no problem. The same is sometimes true on OSX/iOS, but often not. The increasing popularity of Apple products and the lower priority they place on backwards compatibility has definitely made developers' lives harder.
Having said all that, I don't think everybody expects constant updates. I think power users, especially, are used to running what works for them for long periods of time. You probably can't build the next Google on this, but a lifestyle business? Certainly. Just look at Pinboard and it's lack of enhancements or UI overhauls - and that's an online service.
Engineering projects usually have a finished state. Software engineering is no different, no matter how much the industry wants you to believe otherwise.
Imagine the gas stations (operating system) changed the kind of fuel they dispense every few years. No, by no means a car (software) that is fully finished today would be able to continue doing its thing tomorrow, without ongoing updates.
This also happens in the real world, it's just that changes are more likely in the decades or centuries, so we as humans don't perceive them so well.
The fact that Microsoft spends a whole lot of money to avoid this, is circumstantial. Apple doesn't so much, and at some point your finished software will stop working with newer MacOS releases if you don't update it to the newer system versions.
Linux is even more of a moving target. Good luck having a perfectly well working compiled program today, and trying to run it in 10 years time.
Look at macOS for example, which over the years has gained app sandboxing and mobile-like access permissions. Software pre-dating these additions that assumes that it has access to everything all the time will have its functionality impaired. Devs had to update their software to not make such huge assumptions and to handle no access cases gracefully.
> Devs had to update their software to not make such huge assumptions and to handle no access cases gracefully.
Sure. But at some point it will reach the "secure enough" state, won't it?
(Actually, macOS permissions work mostly transparently API-wise. Apps can request access explicitly so it better fits their particular UX, but the prompt would also pop up the first time the protected resource is accessed. No code-level changes are necessary to support this.)
Google is a bit of a special case I think due to their culture of using big projects as a means of climbing the corporate ladder. The only thing that could ever possibly result from that is endless churn.
> Sure. But at some point it will reach the "secure enough" state, won't it?
Maybe, I’m too much of a layman in the field of infosec to be able to say.
> (Actually, macOS permissions work mostly transparently API-wise. Apps can request access explicitly so it better fits their particular UX, but the prompt would also pop up the first time the protected resource is accessed)
True, but it’s still problematic if e.g. the user accidentally denies access unknowingly, which will result in the app producing seemingly nonsensical errors. For a good user experience the app needs to be able to tell the user what the real problem is.
Sounds like it's not "finished" if it needs all these updates.
As for why change the window dressing, the market for style changes over time. Why do car companies change the look of their products? Why does the outside of a cereal box ever change? Do the inside of our houses today look the same as the 80s? The 70s? The 40s?
Are you arguing that Windows and MacOS should continue to look like it's 1.0 release?
Software is a tool, a means to an end. It doesn't need to participate in fashion.
> Are you arguing that Windows and MacOS should continue to look like it's 1.0 release?
Yes. It should remain an option at least. Not the literal "1.0", but the version when a decent UX was figured out. For Windows in particular, that's clearly 95. I know people who used the "classic" theme in Windows 7 and earlier, which remained mostly unchanged from Windows 95, and are resentful of its removal in subsequent versions that they have to use in order to have support for modern hardware.
I wouldn't say that's very clear. There were still lots of refinements and redesign that happened as Windows started becoming more of a multi-user OS with NT and later XP. Just because there was a classic skin in 7 doesn't mean it was the same UX. Even with the "classic" skin there's pretty massive changes in the behavior and usability of most of the UI.
Maybe you find 95 to be the end-all be-all of design, but many don't. UI, and to an extent UX, is partially subjective and then also very different based on the user. Imagine a user who has only used an iPad gets dropped in front of a Windows 95 machine, would they consider it the peak of OS UI/UX design?
And as the product's target market evolves and changes so too should the software for what customers expect. Which brings me to...
> Software is a tool, a means to an end. It doesn't need to participate in fashion.
One could make the same argument of a bed or a couch or hell even a whole house. A house is just a tool, something to keep the environment consistent and shelter from the elements. A couch is just a tool to support a sitting human being. It doesn't need to participate in fashion. And yet people are pretty dang picky about their furniture choices and paint comes in thousands of colors.
Any piece software competes in a market of software. Say there's two pieces of software with identical feature sets. One looks like an ancient Java Swing UI and has bad colors and overall just looks ugly, meanwhile the other looks nice and pleasing (insert your own ideas of "nice and pleasing" here). One is probably going to hemorrhage users over time, can you imagine which?
The windows themselves, the taskbar and the desktop all worked the same in 7 as they did in 95. Many of the changes made over that time came with settings to revert them — like that new thicc taskbar with icon-only buttons and window grouping.
> Imagine a user who has only used an iPad gets dropped in front of a Windows 95 machine
I'm sick of perfectly good desktop UIs getting redesigns which are compromised by the existence of iPads and other touchscreen devices. This just should not happen, period. Windows 95 UI is straightforward enough once you get the basic principles, which takes all of one hour of poking around. Microsoft didn't conduct all that research for nothing, after all.
What frustrated people about Windows 95 (and 98, and ME) when it was current wasn't the UI. The UI was nice. It was the inherent instability of the system itself due to its architecture. Same for classic Mac OS, it doesn't matter how nice your UI is if the system itself can be trivially crashed or locked up by a single misbehaving app because of cooperative multitasking and lack of memory protection.
> One could make the same argument of a bed or a couch or hell even a whole house.
All beds and couches work the same and look largely the same. You know a bed when you see one.
All buttons and text fields and window titles used to also look largely the same and everyone was fine with that. But then the plague of flat design happened.
Imagine being exhausted after a long flight, walking into your hotel room only to see white, textureless walls, floor, and ceiling, and multiple white textureless blocks of different sizes inside. You get to figure out which one is a bed, which one is a chair, which one is a toilet, and which one is a sink! How exciting! This is what modern affordance-less UIs feel like. A good tool shows how it's meant to be used by its form.
> And yet people are pretty dang picky about their furniture choices and paint comes in thousands of colors.
That same classic Windows theme was extremely customizable for that very reason. You could change all colors and fonts to your liking, and some people did! You could make yourself a dark theme way before dark themes became mainstream.
> Say there's two pieces of software with identical feature sets.
You mean the control skins are the only thing different between them, otherwise all UI/UX being identical down to the layouts?
It's almost like you've never been in a furniture store. They come in tons of different sizes, shapes, textures, colors, features, and more. There's not just a single couch model that you can then change the color on.
> The UI was nice.
I highly disagree. The taskbar would get filled up quickly and get squished for me since there was no grouping. The notification tray couldn't hide things. No virtual desktop support. The start menu was incredibly basic in form. No search from the start menu. Editing the start menu programs list was extremely non-obvious and not self explained. Navigating the nested start menu shortcuts was a huge pain. Installers just threw everything in the start menu leading to a ton of clutter. UI elements are miserable at scaling, in that there is zero scaling support. The taskbar was only on your primary display. Difficult to change default sound output device straight from the taskbar. No central place to see previous notifications. No jumplists. No Win+Number shortcuts to quickly swap between things on the taskbar. Alt+Tab prompt doesn't have window previews. I could go on and on and on and on and on about what I perceive to be massive failures of 95's UI/UX.
I didn't really care for the overall icon design throughout the OS and generally see the overall style in the OS as pretty basic, bland, and boring. Changing the color or setting the title bar font to Comic Sans isn't solving that.
In the end though, you probably disagree with a lot of these things. I think your couch is ugly and uncomfortable, and you probably think my couch is ugly and uncomfortable. UI/UX has some subjectivity involved. Not everyone agrees 95 was the ultimate software design unable to be improved upon.
Underlying hardware/OS/firmwares/JVM/etc change.
Dependencies break.
Security updates.
Etc.
Engineering projects usually hand off maintenance to their owner. Your house/car need maintenance. Your cities roads/bridges/tunnels need maintenance.
The difference with software is that maintenance is done by the producers as they own the code.
OSes also can be "excellent products". They don't need yearly updates, there's nothing inherent to them that would prevent them from being made perfect, finished and never updated again.
The only case when an otherwise perfect OS would truly need to update is when new hardware capabilities require OS-level changes to support. Sometimes it may be beneficial to expose these new hardware capabilities as APIs for apps to consume. But again, adding new APIs shouldn't break the existing ones. For example, on phones, this would include things like notched screens, fingerprint readers or multiple rear-facing cameras.
> Dependencies break.
Don't update dependencies. Pick one version that serves you well and stick with it forever. I'm serious.
> Security updates.
It seems like we've already realized that writing code that deals with complex data structures received from untrusted parties in memory-unsafe languages like C is a terrible idea. If you exclude memory safety vulnerabilities, the attack surface shrinks drastically. You'd run out of security vulnerabilities pretty fast if you'd have any to begin with.
> Your house/car need maintenance. Your cities roads/bridges/tunnels need maintenance.
Houses, cars, and road infrastructure are made out of atoms and exposed to elements and stress of our imperfect real world. They wear out. Code doesn't. In 100 years, the bits would be the same they are today (as long as you use a reliable enough storage medium).
theres this thing called the internet, to which the OS connects, filled with adversarial actors, so no this is not correct at all
Why?
There's a thing called formal verification of software.
The perfect OS doesn't exist yet. Right now, I'd rather use some OS than no OS.
Why a perfect OS doesn't exist? Good question. Maybe because the programming field is relatively immature so we're still figuring things out and we don't apply formal verification to everything. Compare that to say, architecture, where we can calculate how much weight a structure can withstand. Or the other way around: what do we need to do to support an X amount of load.
I guess the stakes are lower too. I wouldn't walk on a wobbly bridge, but I don't mind if a desktop app I use crashes occasionally under unusual circumstances. Critical software (say, aviation) is generally written with more care but it's still not perfect.
Even in electronic hardware there's often continuation of design and refinement. Have you never seen a board with a revision number on it?
Real-world objects like these wear out. Code doesn't.
> Have you never seen a board with a revision number on it?
Of course I have. There's a difference though. You can't ship an electronic device that's unfinished with a promise to "fix it later". Yet this is what routinely happens with software these days. Also, if your device serves its purpose well, you'd probably have a "final" board revision with all flaws fixed. If you want to add features to an electronic device, you'd make it a different model, possibly sold concurrently with your existing one to serve people with different needs and budgets.
You just said "engineering". Bridges and roads are engineering as well buddy.
> Engineering projects usually have a finished state
This is the statement I'm addressing. And it's just not entirely accurate. Things change, assumptions get proven wrong, there's always a newer and better way to do something, etc.
Sure your widget was probably about as good as you could do at the time you first launched it, but several years later there's better components available. Or maybe a supplier stops making some part you were using. Or a few years later you start getting parts back failing early in their service life and need to make an update. What was once your finished state now isn't.
Edit:
"if it doesn't rely on any online services"
That is a big IF. How many things don't, at least indirectly? (e.g. by relying on HTTPS, which requires TLS, which requires keeping up with current cryptographic standards.)
> Physical manufacturing is hard, but it at least brings in dollars
You say this as if it's some indelible fact that if you make a physical product, it WILL be bought and you WILL make a profit no matter what, but I think it's safe to say this is objectively false, as many failed physical business would attest to.
> OSS, privacy and wankers reverse engineering your software shrinks your market substantially.
As opposed to in the physical world, where nobody ever cribs your ideas and sells them at a discount compared to you... AKA "Amazon's business model"? (not to mention overseas knockoffs of products
Given all these things being equal then, software has all the same benefits that your parent comment mentioned, while staying at best EQUAL with physical manufacturing, save for maybe higher salaries to the people making your product (arguable in some cases, but on average probably true) but this difference pales in comparison to not having to own a warehouse and manage last-mile shipping costs etc.
Software has expectations that it can and should be changed after purchase through updates/patches/upgrades/saas products. That creates an ongoing cost a physical product doesn't have.
There are tradeoffs and different expectations which make both difficult. I would rather go the software root because I have the advantage of free developer time but someone else might find making 10,000 widgets from China much easier and cheaper. We think software is easier because we devalue what we add and what we really cost
Nowadays businesses use this to create a constant revenue stream from what used to be a single purchase. It's not to service the product, its to continue to soak money from the people who do end up spending on it.
Aside from security updates most software I have, I just want them to stop. No changes, no design upgrades, no "we changed this tier of our pricing" etc. Most of that stuff is working against the customer not for them. Your SaaS model is so you can make money, I have no incentive to pay more than I have to.
You have to pay their recurring revenue if you want them to stay in business and keep the lights on so you can use their product. That's the hard reality. If you run your own server and fix your own bugs and etc. (which is feasible for many here, I'm not saying it's a bad option) then you can "pay no more than you have to".
It's not my problem that they've settled on a revenue model that isn't in line with what I'm prepared to do.
I have worked on FLOSS software and I have worked on non-FLOSS software and I don't see most FLOSS software sucking in a way that non-FLOSS does not.
FLOSS has some advantages - as there is no compelling need to release new features which can drive up revenue and profit (or at least OKRs) for the next quarter, you don't get a constant need to release unneeded junk to try to squeeze the last dime out of consumers. You can actually spend time refactoring the code, or only releasing when it is properly architected.
Most of the servers and smartphones in the world are running on a FLOSS kernel. MacBook's OS derive from CSRG's BSD, and even some of Windows, like the Internet stack, derive from FLOSS. If it sucks so much, why do virtually all major operating systems derive fully, or at least partially, from it?
Whether or not I pay money for it doesn't enter into my calculation much at all.
It is excludable, but more so with SaaS type things: https://en.wikipedia.org/wiki/Excludability
Low barrier to entry is really important for new software. So it’s this struggle with some orgs trying to increase lock-in (Microsoft, Oracle, etc) and a constant stream of new products taking off, dominating the world, and getting knocked off themselves.
However, since then we have come to learn a lot about software. The most important of which is that software, just like physical products, needs maintenance. The world is constantly changing and evolving, and software has to keep up otherwise it'll become obsolete within couple of years. At the very least it must be patched up with newly discovered security threats.
Just look at all the money/effort spent to make features backward compatible, or army of engineers employed by companies just to maintain existing software.
I'd say at the very most it needs security updates. Too much software changes just to change. UI redesigns for the sake of redesign, cramming features that nobody wants so a product owner can get promoted, adding telemetry and analytics to chase metrics that no user cares about, adding annoying notifications and popups to juice "engagement". I pine for the days of desktop software, where I can wake up in the morning and not be worried that some developer 1,000 miles away from me changed my product out from under me because developers gotta develop.
Another benefit of software that doesn't change every week is you can charge one time for it rather than these awful subscription pricing that most software are switching to. They justify subscriptions because "we have to keep paying developers to develop." Not a problem that the user has, so why should the user have to pay for it?
Old, unchanged software is not obsolete. It's mature. Bugfixes only, please.
It makes sense though, if software companies could make just as much money doing less work, they certainly would.
And then there are the "upgrades" that try to force you to pay more.
There was a dev tool that I purchased a couple years ago. Don't remember the name. It was reasonably priced and came with 1 year of support. A bit over a year later I got a notification that they had put out an update, so I downloaded it to take a look, only to find out that it had deleted the version I had bought and my license wouldn't transfer over. If I didn't now buy this new version, not only could I not use it past the trial period, but I'd lost the version I had before.
Yeah, I was pissed. And the company really had trouble understanding why I was so pissed off by this behavior. I did finally find out where I could download the version I had before, but there went my entire workday. And the product that previously I would recommend became something I cautioned people to avoid!
Any successful piece of software cannot realistically just stay still. It has to keep evolving with the trends of user interface. The difficult part is doing it well. BBEdit has managed it.
All of them? Hell I hate it when things change in a way that forces me to give them attention now rather than when I have time. Nothing worse than doing an update and having to rework my flow, scripts, and code just to be productive again. Let me choose when I update my tools, don't force it on me just because your UI team found an even more complicated and torturous way to make simple things ugly and hard - I have my own work to do.
And the market keeps evolving, so you need to evolve with the market if you want to continue selling.
If you do it slowly enough, and cautiously, then existing customers can adapt.
But if you stop updating your app, it's eventually going to lose its appeal and will be forgotten.
Many people I know in my industry have been looking to dump the service contracts for CAD software for 10+ years. No useful added features, no improvements in stability, and no service to speak of through the VARs. What is the point of paying?
> Too much software changes just to change.
But it doesn't imply this:
> I'd say at the very most it needs security updates.
What the parent said about "security updates at the very least" is correct, and sometimes that happens to also be the very most updates that should be made. And sometimes it's that but a little bit more. And sometimes it's that and a lot more.
The hard part is figuring out the right balance. And then, figuring out how to staff in order to achieve that balance.
The "only security updates" approach turns out to be among the hardest to figure out how to staff for. Because the idea is that this software is essentially complete upon release, so the natural business model is to sell it that way, for a one-time fixed price. And then with that revenue structure, the natural cost structure is to move all the staffing to a new project (or to build these kinds of products with project-based contracts to begin with).
But once you've accepted that you should at least be doing updates for security (and I think this is correct in almost all cases), well, now who is going to do those? You have a recurring cost with a non-recurring revenue stream. You can push down the recurring costs as far as possible, but eventually this model just struggles to pencil out. At that point, you'll probably decide to just stop all updates, including security patches.
This phenomenon is why most people making software seek a business model with a recurring revenue stream. It's not an accident that the days of boxed software were also the days of rampant insecurity.
But, you're totally right that the next step in this is often, "well if we have to have ongoing staffing and recurring revenue, we need something for them to do besides maintenance, so let's do UI refreshes and metrics and stuff I guess". It's a test of leadership, to avoid that temptation. Better products have better leadership that is making better decisions about when it makes sense to do more on a product and when it makes sense to mostly leave it be.
And a lot of those updates wouldn't be necessary of software and tools wouldn't offer so much attack surfaces, that they wouldn't need if they cared less about those things as necessary features...
As a user-developer, I'd also be happy with being provided the source (or un-linked object files, or the equivalent for whatever language being used) after the maintenance period was over, so I could continue applying dependency security patches myself.
"Security" patches are something only checklist-driven corporate IT (i.e. people who can't consider use-case) ought to care about. For individuals, they're mostly a cudgel to justify abusive practices and should be ignored.
Now people use it in very interconnected ways.
How do you pay developers to continuously fix bugs, provide security updates and update their software when the underlying hardware and operating system changes?
Have we really strayed so far that everyone's forgotten how this is done? Security fixes and serious bug fixes should always be free (At least going back N-1. You price that work into the sale price to begin with), and you get ongoing revenue by selling new versions.
They will still need to buy a new version or should that be free?
If the author of BBEdit never added a feature since 1991. You would have still had to pay for new versions to run on your PPC/Classic MacOS, OS X PPC, x86 Mac and now your ARM Mac.
Back in the “good old days” MS Office cost $595 for ea h version if you had a Mac and Windows PC.
Now it’s $99/year for five users and you can run on your Mac, Windows, iPad, iPhone, web, or Android device.
The same for Photoshop.
And you get continuous features added as the platform vendor and software vendor add more capabilities.
This works exactly up until the moment that your software is good enough that most of your userbase stops paying to upgrade. Then you are dead in the water, and the software becomes abandonned by design.
There's a reason farmers want the ability to repair their own tractors without having to give John Deere an extra cut, you know.
Two decades ago, for instance Apple was still selling PPC based Macs.
George R.R. Martin pretty famously uses WordStar on DOS. I can't imagine it'd be some win for consumers (either Martin personally, or downstream enjoyers of his books) if he had to be on the latest internet-connected, ad-infested, notification-riddled copy of Windows just so that his OS and Office Suite could repeatedly check to make sure he still has an active subscription and a valid "digital entitlement."
I still use Office 2010. (Though it gets increasingly difficult to activate it, and it last received security updates in 2020.) In 2010 I was using x86_64 (an Athlon 64 X2), and today I'm using x86_64. Why should I upgrade? It happens to still run on Windows 11, but I'd gladly stuff it in a VM to continue using it. (I do use Office <current 365 build> for work, so I can pretty confidently say there is nothing worth paying for in there. The only feature even remotely interesting is PowerQuery for Excel, which is available as an add-in for Office 2010.)
We each get 1TB of online storage.
Compare that to the $599 that Office for Mac use to cost and that you could only use on one computer.
Of course there is, but that's why software in a box cost hundreds or thousands of dollars per version, with minimal bug or security updates thereafter. The grass is always greener, yeah it's a pain in the ass having a ton of $10/mo subscriptions. But I'd much rather have that - as both a consumer and a developer - than have $800 single-sale purchases.
This assumes a waterfall approach to development which implies multiple 6 month to year long development cycles.
In reality, a mature stable project can receive monthly updates, and an immature half-working project can be in maintenance mode. Furthermore this may work for software that should be seen and not heard doing its job in the background without much user interaction, but for software that users interact with regularly, the design needs to be periodically refreshed to match current trends or users will leave for the newer sexier product with fewer features. We've seen this time and again. I have absolutely experienced a mature product that was "finished" (abandoned) like 4 OS version ago that just doesn't run/work on the current OS version because the platform has added new security controls, APIs, and/or UX expectations, etc. No amount of security updates would fix that.
So while I understand where you're coming from opining for a world where we ship mature software and security updates only, I don't think it's remotely realistic given the way humans operate.
Software that gets frequent updates isn't "mature and stable" by definition. It's constantly changing.
That's simply not universally true and it's incredibly naïve to try and assert that it is. Obviously there are examples of immature unstable software that receives monthly updates, but it's not a tautology that monthly updates imply immaturity. You either don't work in software or haven't really thought this through.
Stable means the software run reliably without major issues and mature means it is a solution well adapted to the problem domain and solves a problem with grace, tried and true. Monthly updates might be "integrate support for new technology/service (that didn't exist 6 months ago)" or "support latest changes in macOS 14" or even "fix issue that happens 0.01% of the time". Other software changes and you have to adapt, and no software ships bug free. Being mature and stable means you have the time to work on things that aren't existential for your product/business, like adding convenient support for some sexy new service as a nice value bump or making sure those 0.01% of your users aren't occasionally encountering an annoying or frustrating issue.
Most people in engineering roles think the job is done when the engineering is done, and the maintenance is unnecessary unless it's necessary for stability or security. That's not limited to software, either. The fact is, to the vast majority of non-developer software users, an improved workflow, more intuitive, or yes, even more attractive interface makes more of a difference than moderate performance upgrades or minor stability improvements.
To a developer, interfaces are a way to interact with with software, like an API for humans. To everyone else, the interface is the software. Old interfaces are as or more usable to you because you have a sophisticated mental model of software and a high tolerance for logical complexity. These dreaded designers' profession is figuring out how people who don't have those things can most easily solve their problem with the tool you built.
Car controls would look a lot different if the engineers maintained control over the available controls without designer input. They might intuitively understand that the array of controls that change fuel injection parameters should only be used in certain instances, but they liked having them right there just in case. When told that they'd just confuse average drivers and should probably be hidden, they might argue, "I explained to my 6 year old nephew how more or less air can affect engine preformance." Multiply that by the dozen internal systems they want to control or get real time data from. A designer world recognize that this would confuse most drivers for little benefit and hide everything but the things most drivers need to find and parse instantly... And they would be met with the same heavy sighs and eyerolls that software designers regularly get from developers.
Designers are in the organization because they can do things that developers can't. They make developers work vastly more useful to the world because the way someone solves their problem is as or more important than it being optimally solved using the smallest amount of available resources with 5 9s of reliability instead of 3.
And that's why, in the overwhelming majority of cases, end-user-facing commercial software with professionally designed UIs and someone looking at UX on a whole will dominate FOSS alternatives while tools targeted at developers and other technical people do as well or better, and the commercial equivalents.
It is really easy to get caught in the trap that YOU are the end-user, but a couple user interviews will quickly shatter that reality.
You're touching on the real problem, here. Software isn't broken, it's just that the inherent issues in capital are starting to become painfully clear in this context.
I've been trying to find a term for "behavior focused on maintaining your job when the need wouldn't exist without such behavior". It's kinda tangential to artificial scarcity but broader in scope, and if we don't have a term for it, we need one badly. So much of our society's resources are committed to solving problems that don't exist, because the actual problem is "you need money to live and for whatever reason the thing you do in the place and time you are isn't necessary or desired".
The concept of self-preservation or calling it superfluous self-preservation probably works here. But perhaps saying auto-preservation conveys better the sometimes lack of conscious intention that goes on in these situations.
and then you move the bar a little (although I agree):
> Bugfixes only, please.
I would also add updating to work with the current OS / hardware. (I have unusable games that are a recompile away from being usable.)
But I agree with the rest of your points. Especially when, in addition to asking you to fund new features, the new features make the app worse for your use cases.
However I don't know if the root cause is more accurately described as "developers gotta develop" or "product managers gotta produce".
Software degradation is much like hardware degradation: it happens with time as underlying platforms change.
I mean, sure, this is what all the software developers have been saying...
In the meantime, I'm constantly seeing users, even here on HN, complaining about how their favorite software tools are changing. Users the world over annoyed at SaaS, and pining for installable software that they can just put on a machine and never have to worry about forced upgrades or annual maintenance fees, etc., or even the convenience of not needing an internet connection for it to work.
The software world has never been black and white. There are product niches, and also use-case niches. You could probably make a good business by choosing something that's only available as SaaS and releasing a local-only version of it.
Only if it talks to the internet. I have plenty of software I downloaded over a decade ago that has no internet access and runs perfectly fine on Windows 11. Much of it is even older than that. Just stop trying to cram social media integration into your label-making program and it gets a lot easier.
So.... Most software.
Agreed
Take into account maintenance when pricing your software.
Like 9/10 apps need no internet connectivity at all, unless they are spyware of course, which most commercial apps are nowadays.
There are plenty of open source libraries, that many software developers used in their applications, that have had to have security updates. No software will be 100% secure.
"Like 9/10 apps need no internet connectivity at all"
This might have been true 10 years ago. Almost all apps people want need internet connectivity.
The whole connectivity thing is the fundamental problem. Transferring files between devices have never been as easy as during the floppy disk days. Usability is not the driving factor behind forcing the internet into everything.
There's some truth to this, but I think this factor is usually dramatically overstated. At least, most of the software I use doesn't need to constantly change. The majority of software updates I see are unnecessary, and many of them are undesirable.
I left before they upgraded anything, and they're still in business, so I guess it worked out. But it proves that not everything has to change to continue to work.
> ..not everything has to change to continue to work...
That was sort of my argument; you could make do without changing the software but the cost keeps increasing and the user base keeps shrinking. At some point it'll be down to that one customer who refuses to budge and will be asked to make a tough choice; upgrade to the latest version or hire developers yourself to support...and even that may become impossible if h/w guys stop manufacturing that old machine configuration.
I feel this is largely being overstated point, or rather that in reality majority of important patches for software is due shoddy quality of it originally rather than external changes. Most security issues are rehashes of common well-known attacks rather than completely novel discoveries. Especially on desktop the platform churn is pretty low, windows happily runs like decades old binaries, and on Linux desktop we have this one major breakage happening that is Wayland but otherwise well-written decades old code is at least source compatible if not binary compatible (although even that is not that far-fetched...).
Each line of code is a burden of future maintenance.
I'm not sure exactly what you mean by this, as a large part of software development is QA testing, and validation. Which is a form of quality control.
You need a QA/QC process to identify units which are too far out of tolerance and either remove them from the pipeline or remediate them. You also need to track trends in the measured tolerances to proactively fix your production equipment.
In the software world, that’s trivially easy. Your CI pipe publishes an artifact and then every user gets a bit-perfect copy of that artifact. Your entire QC is just: Users compare the artifact’s checksum to the expected checksum. It essentially always matches because we use things like TCP to copy the data.
The type of QA you’re talking about is also required for physical widgets.
Maybe you've never experienced the difference between writing software for 1000 people and writing software for 1M people, or (I imagine) 1B. The marginal per-person cost of software is not on shipping. It's on "what kind of weird shit will I now have to do because 1M is a lot of chances for my software to break weirdly, and people have paid for it"
> You don't have to worry about quality control and returns.
You don't have to worry about quality control and returns if you don't care about quality control or returns.
But if we're talking about plain old regular software, something that needs no server to operate, and functions perfectly fine offline, something like, say, Photoshop, how different is the impact on the manufacturer when the software is used by 1k users, 1M users, and 1B users?
Yes, having 1M or 1B users means more opportunities for the bugs to surface and for people do be upset with the product. But do those scenarios impact the quality of the product for other users? Does they introduce unseen costs to the manufacturer? Do they make the product unprofitable or unsuccessful in anyway? Or does it mean that the manufacturer will have to refund 0.1% of their sales, and only benefit from the 99.9% of sales where the product worked as expected?
_very different_, when the user's environment is different. And 1) you haven't seen shit if you think you can perfectly control the user's environment. 2) every new user is a chance for the environment to bite you.
> Do they make the product unprofitable or unsuccessful in anyway?
You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to.
Can you provide some examples of this? I'd like more info here, because off of the top of my head, I can think of the following counter-examples:
1. This isn't a new problem. User environment has been an issue ever since software as an industry was born. Specifying minimum specs is a pretty typical thing. And while I don't have depth of knowledge on these challenges or their history, my understanding is that it's only become less of a factor over time. So why is digital software different in this regard? If the industry was able to sustain itself before it went digital, what about the change to digital makes it unsustainable now?
2. Computer games, which are probably a good candidate for the most resource-heavy programs that need an appropriate environment, still largely adhere to a pay once business model. Doesn't this indicate that offline experiences aren't affected by environment to such a degree that a single payment business model isn't problematic?
> You do your engineer best to try and fight that. But there's absolutely a marginal cost, which is what I was responding to.
It surely has a marginal cost. But is that cost significant, is the question. In particular, significant enough to warrant a recurring payment business model.
I think you're assuming more of my answer than what I gave. That's fair given that this is the point of the article, but it's not mine. I'm very specifically only responding to "is there a per-user marginal cost on software?", and my answer is most definitely yes.
To warrant a recurring payment business model, I think the right question to ask is "Is there a per user-year marginal cost on software?", and now the answer is in my view, much more complicated and domain-specific. Worse yet, I think that there's perverse incentives at play here in recurring payments.
Fair, but I feel it's disingenuous to ignore the context the original comment was written in (the context of the article) and try to argue against a specific point in the post as if it was made without that original context. The sentence may have lacked inherent context, but it was supporting the key points the GP was making in response to the article. It wasn't designed to stand alone.
Given, I'm not the author of that post so entirely possible they were intending for it to stand alone, but I think it would still be better to see if that was intent rather than to assume so and antagonize what they were saying.
Try selling English-only software in Europe and you generally won't get very far.
If a company was only able to sell 2.6M copies of their digital software before running to expansion problems... good for them! That's a lot of sales and they probably made a great deal off of those sales. Sure, they can grow to 1B users, but they don't have to. There's no requirement for them to do that other than choosing to expand into those markets, and that's strictly optional. The business model is doing fine, there's no need to adopt a recurring payment system for ongoing maintenance.
And let's be honest, even if they do choose to expand into those other markets, the cost to convert the existing product to work in those markets is most likely less than the money they'll earn from selling in those markets, so... is there really a need for recurring payments to support maintenance? Will one-payment sale structures inherently fail to make the product profitable in a given market?
Absolutely. Anything involving internationalization is an open invitation for very weird edge cases. Some languages (Hebrew!) are written right-to-left, some require more than one byte to store (Japanese, Chinese), time formats and time zones vary, some write currencies with the symbol in the front (US dollar) and some at the end (Euro).
If all your testing was done by Americans speaking English, the only thing you may stumble upon is timezones. If you're in Europe, timezones won't be much of an issue (as almost everyone is on CET), but you may find out that, whoops, Windows localizes certain path elements like C:\Users.
On top of that, a constant pain point in support is displays. Most Windows users are on a 1080p screen on their laptop, but may plug in their new 4K monitor and notice that your UI is completely illegible because it doesn't respect DPI settings. Or you thought you supported variable DPI, but never planned on a user stretching your window across two screens with different DPI settings. Or monitors use different color profiles or gamma settings and users complaining about that.
The main product at work is a desktop application. That means that every OS version / hardware configuration of every platform that any user might install it on can have its own bugs. It means that we support multiple major versions rather than being able to just always deploy the latest version. It means that a user might want to have multiple versions of the software installed side-by-side on the same machine. It doesn't change the fact that more users means more use cases.
I don't believe such software exists. (And, to be clear, I'm writing from direct, day-job experience.)
EDIT: I take it back. SQLite, cURL. Maybe.
EDIT2: I can't reply to the SEL4 response, so here goes. I'm a huge fan of verification tools, but consider the Spectre class of bugs. Verification is always done wrt a mathematical model that you've defined after inspecting the world and writing down the properties you want to track. But the world changes, and the chance that the world changes increases with the number of users of your software. That's the nature of the beast.
When I had a reply I couldn't reply to, I opened the reply separately in a new tab, and there I could reply to it, try this.
It's a bug in the processor that causes a bug in the software. It's not a bug in your idealized mathematical model, but try telling that to the people who paid you not to leak private keys.
I see my job as an engineer to be to create a product that satisfies the user's expectations (which in this case are eminently reasonable). It matters not one bit that I can point the finger to the chipmakers. I'm still selling something that I now learned doesn't do what I said it would. It's still on me to fix it the best I can. If I care about the product quality, that is.
Not my business to decide what you think is reasonable. That's just what happens in the world, and what (in my view) good engineers sign up for.
Why do you think so?
What choice? I have to fix bugs today as they come.
I think that this is a bad analogy to hardware, though. Polished steel roads are unreasonable to ask for, but bugless processors are reasonable to ask for.
I’m software we deal more with curses than miracles. Those happen every day too.
Software use cases experience combinatorics, and almost all useful algorithms have log(n) runtime. Even when Knuth says they are O(1), physics or EE say he’s wrong. There are no economies of scale. Racks don’t get cheaper when you run out of network ports. Cooling doesn’t get cheaper when you run out of roof. Things that failed one time in a million calls now happen every hour instead of twice a month, and actually have to be fixed.
It’s death by a million cuts.
Take for example any mobile app. Apps require constant upgrades to keep up with the hardware and software changes on the platforms. You can’t just build an iPhone app and leave it alone to be enjoyed by people. I’ve tried, within a year or two there will be changes that require developer work, if you don’t keep it maintained, it will start to crash and function poorly, Apple, for example, tracks everything and will start with de-boosting search results for your app and end with removing it from the platform entirely.
Google is the same. I’ve tried, I built a Top 25 RPG and got busy with other things. It went from Top 25 to deplatformed in less 5 years because unmaintained software just doesn’t work in most cases today.
Software is more complex now. All software is a conglomeration of lots of other software: frameworks, platform tools, libraries, APIs, etc.
Another example: Flash
Another example: All the AI software being written on top of the OpenAI API will be broken in a year or two as they roll new versions of the API and deprecate the old.
Software doesn’t just work anymore. The platform that executes it is constantly changing.
My favorite is when a new Apple update breaks your app, so you identify where the issue is and make a small update, but now Apple rejects your update because of some other arbitrary guidelines it's changed, so you then have to start down that rabbit hole.
It depends on the software. But where this is true, it's not because of some innate nature of software, it's because of business decisions software companies have made.
Unlike hobby software, where you could reasonably write everything from scratch just for fun, or say in write it in 6502 ASM which hasn’t changed at all for 50 years and won’t change in 50 more, in modern business software, you use common frameworks, APIs, platforms. All of those mean the software you write will fail as those dependencies and platforms change and age out.
Business software has to be built on common building blocks because as a business you need to be able to hire people who can work on it. So things like Java and node and react and dozens of APIs exist which creates dependencies and requires ongoing maintenance as those components continue to change.
- How does this feature work?
- How does the software do this?
- you said it does this and it doesn't why?
- can make the software do this?
Each one of these questions cost money to answer and needs someone to hand hold the user. especially if they are a non-technical business user.
A few offices, macbooks, and data center space is very cheap compared to building a manufacturing plant.
On the other side, what tech people understand that the general public does not... is that software has a healthy dose of maintenance and operational costs when it scales. Not a massive cost, but higher than zero - which is what most MBAs think the maintenance cost is.
* Software is extremely expensive. Software engineers are expensive, and for a good software project you need a tech lead, a manager and probably a few developers. These are all people you need to pay tons of money for.
* Software is constantly changing, something that worked 2 years ago can be broken beyond repair today. You need a team that can keep up with this.
* Software needs maintenance. You can't just build an app an call it a day, you need to employ a team to maintain it continuously. You can build a massive, gargantuan bridge and maintain it maybe every few years/half a decade to keep it safe for 30+ years, you cannot do that in software.
* Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades. What a developer focuses on while writing code is mostly ideas developed in the last few years. Although you think you're building a simple app with 3 devs, what you're missing is you have your own tiny research lab studying how to develop this simple app the cheapest way possible while making it maintainable.
* Software by its very nature is hard to make money off of. Its complexity is opaque to most people, they're not willing to pay. You'll always have people pirating it, eating away from your bottom line. Moreover, each new software means changing workflow, so even if you have the best product on the market, decent amount of people won't switch from the industry standard.
* Modern software engineering methodology focuses on, among other things, time to ship, feature richness and maintainability. It does not focus on correctness -- partially because our theories on software correctness are lacking (even if you decide to use novel/extreme approaches such as Dependently Typed Programming, formal proofs etc it's unclear/unknown if you'll reach a significantly better correctness metric). This makes your product inherently frustrating to the customer. No matter how much money you spend, you'll always have a product that's a little bit buggy. This means the product is very sensitive to the amount of money you throw at it. If you throw Apple level of money, it'll be less buggy, if you have a barebones team it'll be more buggy.
> * Unlike what outsider think, software -- even "boring" CRUD/web software -- is still very much a research project. If you ask a civil engineer how to build a bridge, they'll tell you about all the techniques that were developed over the many many decades.
As a nonpracticing civil engineer, you're underestimating the ongoing maintence that goes into any large bridge.
Also, though the techniques may be more established, every bridge must still be designed to fit the specific characteristics of its local geology and geography. But come to think of it, fundamental computer science algorithms are pretty well established, like bridge-building techniques. Software engineering is simply fitting the code to each unique problem, as bridge design fits a bridge to each unique place.
Most (all?) of the ideas I see are at least 20 years old, if not 40-50. Something like Spring wouldn't be my ideal choice, but it can certainly get the job done for most people, and it's 20 years old. MVC dates back to the 70s. Postgresql is 27 years old and is a fantastic choice. SQL and RDBMSs date back to the 70s. The term CRUD itself dates back to the 80s. Server rendered pages are still easy to do, perform way better than most React-based abominations, and are as old as the web. If anything, software is plagued by these "research projects" that are mostly just to scratch smart people's itches.
That must be why most software startups succeed.
Hard tech startups are notoriously harder to get off the ground than software companies.
The fact of marginal cost results in a lot of software being written that otherwise never would have been. After all, the difficulty of solving a problem for myself often doesn’t offset the trouble of making a reusable solution. It’s only through having other people use it or pay for it that it becomes worthwhile.
Randall Munroe’s chart is incomplete because it thinks too locally.
I'd argue in all domains, the hard part is making an excellent product.
There are virtually zero real-world constraints you can leverage as excuses in the domain of software, other than the original idea was bad or you have really bad people around the idea. Most of the software ideas I have encountered in my career are fantastic. It's not hard to describe what a high quality product experience is like if you are a domain expert and have suffered the gauntlet for 30+ years. The part that always seems to go straight to hell is the implementation of the idea.
I suspect most software projects go bad because there are too many layers of separation between participants. In physical products, substantially more direct interaction is required to get things done. With software products, you can isolate everyone into different multiverses as long as they are pushing PRs to the same GitHub repo (and sometimes not even the repo is shared...). Over time, these silos ultimately ruin any sense of ownership and quality in the product.
It is quite tragic - while on one hand software is the most accessible form of human enterprise ever, it is also the easiest to do wrong. Having no constraints seems like win-win at first, but it is absolutely a double-edged sword. In my view, the best software company CTOs are the ones who intentionally add as many artificial constraints as they can to the technology and process. Do more with less. Force lateral thinking. Make the product people go back to the customer and say things like "we actually can't do that because of a technology policy" instead of pretending like an unlimited infinity of things is always possible.
This is exactly why people should pay for software: consumption of physical goods destroys the planet. Money spent on software can't be spent on destroying the environment.
Ban ads*, make people pay for content and software and save the planet. Win-win-win.
* most of them anyways
Software is easier to produce, sell, and distribute than any physical product. You don't have to worry about warehouses filled with unsold inventory. You don't have to worry about quality control and returns. It still blows my mind how much easier it is to run a business that deals with bytes instead of atoms. The OP talks about software having no copy protection, but Amazon sells DVD players and cordless drills for $30. Imagine for a second how hard it is to compete with that. Competing with Google or Microsoft or some startup is a walk in the park in comparison.
In software the hard part is making an excellent product. And let's face it, that's where most people fail. It has nothing to do with monetization.