Is Software Getting Worse?
stackoverflow.blog
stackoverflow.blog
Software simply does a lot more than it used to. A lot of people are complaining about chat clients. Today's chat client is a lot more complicated. Sure, go back and use IRC from thirty years ago. Do you remember all those commands? slash-something?
And all that old, simple software is still there if you want it, better than ever. Go get Emacs, or vim, or mutt, or your old IRC client. Go download MP3s and put them in your folders and use a command-line program to play them back. Nobody has taken any of that software from anybody.
And if I want to develop that simple software, it's easier than ever. A Common Lisp compiler used to cost big money, and even a C compiler came in a shrink-wrapped box, unless you had heard of GCC - which was hard because there wasn't much of an Internet. Now I can download that stuff for free. On my Mac I can get the same tools pros use, for free. Microsoft used to charge big bucks for comparable tools.
Software is not getting worse.
Not a lot. A tiny bit. They are still displaying text and a few images, and struggling to do even that (I wonder if Slack still needs 20% CPU to display an animated GIF). And yeah, slash commands are stil there.
> Go download MP3s and put them in your folders and use a command-line program to play them back.
Yes. We can play them back with Winamp which has all the bells and whistles that modern players have, for a fraction of resources.
> Software is not getting worse.
Current software struggle to do many of the same things that software of 20 years ago was already doing even though modern software has several magnitudes more resources.
-server saved history
-custom user uploaded emotes
-threads and channels
-native gif and video support
-image embedding
-voice and video streaming
-complex automation apis
-detailed and comprehensive moderation systems
None of these are optional or superfluous. If you wanna go back to everyone having to run their own bouncer, approximately 5 people will join you. Tell them that they can't even have emojis and your probably down to 0.
Do you really truly think that all you listed is or somehow should be difficult on modern hardware? Or that the truly abysmal performance that modern chat apps exhibit can somehow be justified because they embed things many of which are either handled by hardware (images and video) or by the server (states, history, automation)?
If I could save some bucks removing videos, emojis, voice and video streaming, I would not hesitate in do so.
You got a fair point on how things work: it's all about communication. You want to stay where everybody is, so the incentive is to capture market, not make a fast software.
I think that most of the innovation effort in the last decade was on how to delivery fast.
Pretty ridiculous oversimplification. Hard to take posts like yours seriously tbh.
So you completely forget AIM/ICQ/MSN existed? They did basically everything modern clients do in a couple megabytes of RAM. Jabber even more so.
In the AIM/ICQ/MSN days, the userbase was much more niche as it was not user friendly.
Simple changes like responsiveness or aesthetics help less adept users adopt and use technology.
Furthermore, technology is now global. You will need to support more fonts and languages. You will need to test for various different localizations. You will also have to add support and localizations for the less physically able.
I think if anything their interactions were more clearly designed. Have you tried the likes of Snapchat where you have to just paw at the screen until you learn what your pawing does?
OS level text rendering was basically solved by this time in the early 2000s. I definitely spoke to people in Japanese on ICQ in 2000/2001
Not for all languages.
For starters, my ancestral language's Unicode support didn't arrive until 2008. In that same Unicode proposal, support for a language spoken by 22 million people was added as well. Additional blocks line for languages like Laotian, colloquial Khmer, etc weren't added til the 2000s.
Also, plenty of languages (eg. Burmese) don't use Unicode fonts and instead use localized non-standardized blocks such as Zawgyi.
The internet in the 1990s was designed with the North America, Europe, Japan, South Korea, Taiwan, Hong Kong, and Singapore in mind.
The majority of the world wasn't on the internet yet and hadn't even used a computer. The form factor, usability, and documentation needed simply didn't exist in the 1990s and early 2000s yet.
The Internet didn't truly "democratize" until low cost smartphones like Samsung, Oppo, and Xiaomi began entering the market in the early 2010s.
> Have you tried the likes of Snapchat where you have to just paw at the screen until you learn what your pawing does
Yes. I was the target age demographic for Snapchat. For people who's primary experience with computers is smartphones (aka the majority of the world) an app like Snapchat or WhatsApp or WeChat or TikTok is easier to use than folders in Windows, MacOS, or Linux, let alone terminal or IRC
The incentives to write software may have shifted over time as well. I seem to recall a lot of good quality, older software being written as a passion project. While those still exist and are being written today, the stuff that gets shown to you in a google search (usually) isn't that. Takes away the incentive to build anything that isn't backed by an investor looking for quick returns.
This is more of a problem with Microsoft Windows products before they universally adopted the NT kernel across their product line. The instability of the 16-bit kernel and its 32-bit extensions was a constant point of ridicule from users of other architectures and operating systems at the time.
EDIT: unless you prefer one of those unix things in which case good luck even getting graphics
I had a hearty chuckle at this bit. It’s completely out of touch. Modern software development is far from simple. It also requires an Internet connection for getting packages.
uncommon thought: downloading this from the internet sure is more convenient than already having it
You know, you don't need the internet to develop software, you can still do it exactly like we used to in the 80s. Download gcc and start reading man pages.
When I worked at places making software that would be sold to users on floppy or CD in stores like Best Buy and CompUSA back when very few of those users had internet connections these things were true:
1. If a user needed help beyond what was provided by the printed manual that came with the software and whatever help system we built into the software itself they would call our toll-free support number. The typical cost of such a support incident was more than our profit on selling the software to that user.
2. To distribute bug fixes to existing users we'd have to mail them floppies or CDs.
3. The only future revenue we would get from existing users would be from them buying more of our products.
These factors made management place a heavy emphasis on not shipping software until it was good enough that very few people would need support, that whatever bugs we missed were not severe enough or numerous enough that we'd have to ship updates, and that users would be happy enough with it that when they saw other products from us they'd want to buy them.
You released your product when it was done, and then you moved on to work on your next product.
When internet became the main means of both support and distribution much of that changed. Support became a lot cheaper for the developers for a couple reasons. First, users could turn to community forums that would often solve their problems without the company even getting involved. Second, if they did contact the company it would be via email or a web form rather than an expensive toll-free phone call.
Distributing updates to users became routine, and even automated. Accordingly the number and severity of bugs that can be in the first release has gotten higher. It just has to be good enough to not piss the user off too much before you can release an update.
The net (no put intended!) result is that nowadays people release at a stage when they have features and bug levels that in the floppy/CD retail days would have been considered beta or often even late alpha.
So it is not really that software sucks nowadays compared to back then. It is that back then users didn't even see the software until it was finished. Nowadays they get the software while it is still being actively developed.
If you were one of the privileged few who had Internet connectivity, maybe you could ftp some useful stuff, or maybe not.
What libraries and such did exist were mostly sold through the mail from ads in the backs of computer magazines. On floppy disks.
The valid excuses for some of the footprint these days are bad protocols (but you pretty much have to use them - JSON is an abomination for resource use), Unicode, and higher resolution assets. There is actually very little else that's driving it other than horrible coding.
One way you can tell is that performance SW hasn't really bloated the way desktop and mobile software has. Postgres? Still pretty tiny and scales as you'd expect. Compilers? Even Excel isn't a huge pig the way the electron apps are.
Slack is so bad it is actually hard to think of a software application that is worse, and barely does anything more than most other, lighter-weight applications of the same sort.
MS Teams comes to mind. It's more bloated and it lacks some of the features of Slack, or implements them in a user-hostile way locked into other MS products.
I was back "in time" and I'm much happier with software these days on all levels.
True enough. Modern software does a lot of extra stuff that the user neither asked for, nor wants. This is a double hit to software quality. Not only is there the added complexity of all that crap in the code base, but the intentional "crapification" when everything is working as intended. A recent example: https://www.tomsguide.com/news/assassins-creed-in-game-ads-a...
To me, this is the main problem. Most software now has so many features that the owning company can't possibly keep eyes on it all anymore, or just chooses not to as a cost cutting measure.
Simple example that has hit me lately: simplified view in Chrome on Android does not work anymore. It just shows a loading spinner forever. I would bet money Google has no idea or just doesn't care (surely they collection exception metrics?). I hit stuff like this all the time now. I just fully expect say 10-20% of features in a modern app to just flat out not work.
I was there too and I think your glasses are a bit foggy. I can give you one example. Windows had a bug where some timer rolled over every 42 days causing some minor issues with applications. Today windows reboots your machine every month! I think about this often. You should too.
That was my first thought too. My second thought was that was 30 years ago. Different people may be using a different era as a reference.
When it comes to software reliability, the industry appears to go through a push every once in a while. In the mid-1990's there was a push to introduce memory protection into personal computer operating systems. Software became more reliable because it was protected from other software, and because it became more difficult for software to trash the operating system's memory. In the early 2000's security was a much greater issue, so we saw another push that affected software quality. Well, several pushes. So yes, there has been a definite improvement in software reliability in some respects.
Yet software reliability is also about the people sitting behind the keyboard and writing the code. Better operating systems and better development tools may help to catch some of their errors, but it won't catch all of their errors. If they try to (recursively) calculate the Fibonacci Sequence with `f(n-1) + f(n-1)`, the computer will gladly do it and gladly produce the wrong result. Of course development tools aren't infallible either, and what they catch depends not only upon which tools you use but how you use them. For example: C won't detect integer overflow. Rust appears to be somewhat better. It will detect overflows in debug builds, though it will only not detect overflows by default in release builds. It also offers functions to handle overflows in various way. But as soon as you depend upon a developer changing a default or making an explicit function all, you are bumping into the same issue as the Fibonacci Sequence example: the computer is going to gladly do what the developer told it to, even if it is not correct.
Even though software reliability is tremendously better than it was 30 years ago because of technical improvements in the operating system and development tools, I suspect it also ebbs and flows on shorter time scales simply because there are entire classes of errors that are affected by the people who develop (or fund the development of) software.
(Edit: in a twist of irony, HN was not responding when I initially tried to post this. Another point is that the reliability of a lot of modern software depends upon external services.)
I remember all of this, and it was a lot of time ago. XP was more stable than Vista. Then, Windows 7 arrived and became the most stable Windows version ever. Windows 10 and 11 turned out to be overbloated and problematic. I remember using uTorrent, which, after Azureus, felt like a breath of fresh air. It was written in C, super fast, small, and efficient. Now, it too has become an overbloated mess. In the last 10 years, the huge demand for software has led to many people entering the field without adequate understanding and knowledge about software enegineering, resulting in a market flooded with buggy, overbloated software.
Hardware has gotten better. Much, much better.
But I still like to use old software. Because I find it's the only way I can appreciate the new hardware. New software is far too unilaterally manipulative and exploitive of both the user and the user's hardware resources, often for ridiculous, unnecessary purposes such as data collection, surveillance and advertising services.
If our tooling and efficiency is getting better, why would we not be able to automate a wide variety of efficiency improvements as mere compiler tasks and get away with it?
It's not. The life cycle prioritizes process over product and real-life constraints, thereby making software engineering a drive-by operation.
Many of our software engineering methods today are discardable and thus unsustainable as well.
We need to bring back the notion of developer attention and stop relying on mere tooling for improving our software. Our tooling is only as good as we are, and tools are also written by oblivious software developers, after all.
We need to have ways where software developers look to perfect their art, understand the basics, dive bit-by-bit and get back to improving their applications. As opposed to simply complaining that their Electron based application is slow.
They have to work with employers and teams who allow them to do that, at least once in their careers. That may get them to understand a lot of issues better and will lead to better outcomes for themselves and everyone around they write software for.
There are many things a disciplined person could do, yet discipline is hard: picking a few places to do this sort of work is a great way to start this transformation.
Sustainability and maintainability are a huge issue though that can kill products as development gets slower and slower. However, that at best orthogonal to things like resource consumption
More features do not necessarily translate to better outcomes. Features will often be measured at a point in time. It has to be good enough for people to use a product and not inconvenient enough for people to run away.
More development does not mean more usage. Imagine someone in utilities connected your home to a power supply and then decided to periodically change it just because they need to show that they work - and not to be useful to you. Would you like that? That sort of active development thing is found seldom outside the subscription based SaaS business.
Case in point: AWS, you have dozens of services launched every quarter and maybe its developers there get bored and launch new services, yet most people use those few key services a lot and are happy to stick around as long as things don't break terribly.
The issue is that we've come to liken features and bloat with usage. Then we assume our customers want that bloat and can afford to do so. Mostly at that point, companies are optimizing for their own development over customers needs. Over a period of time we get disillusioned that our bloated software is often what our customers need. Then when that doesn't work well, try explosive methods such as platform obsolescence. Thus leading to loss of sustainability.
Grab a person off the street and ask them about how they feel about the quality of the software they use at work, at home, on their phones, and I bet they would be quite unhappy with it, but feel that this is just the way software is. What consumer would risk paying £100 for software when they expect it to suck anyway?
Without a demand for good software, suppliers are constrained to turn to alternate value streams like retention or data collection, creating worse experience for the users, and perpetuating the cycle.
So this is all you say that you can't look at the market at a surface level and immediately draw conclusions about what people fundamentally value, because the structure of the market is path-dependent. What may seem like end-users caring or not caring about something might be more of a reflection of choices made within systemic constraints.
How do you incentivize quality? We've seen two approaches that definitely don't work super well to deliver consistent quality. One is "proprietary, make people buy per unit" and the other is "free and open source."
(And note: I say the latter as a huge FLOSS fan. I'll still push it all day -- but only because I think freedom is more fundamental than quality in this regard; preserve freedom first, then we can think about quality control.)
Closed source products can be sold outright, rented, subsidized via ads, some combination of those, and more. They can even be given away as tax write-offs or loss leaders or somesuch.
All of those models also exist for open source products! It turns out that customers aren't paying for source access so much as they're paying for working software.
No one can agree about what "quality" actually is. Mostly, it's a word used as a weapon whenever someone wants to bully change into happening. Or not happening, for that matter. But a weapon either way.
Good point on "quality," it makes a lot of sense to try to look at the thing we're talking about here without talking about "quality" or "software."
There are problems and opportunities in this technological space; what good ways are there to handle those, noting that much of the work that needs to get done for them isn't likely to occur without payment? Something like that.
Bandwidth, storage, CPU, memory have all ben unconstrained for ~ 10 years now. Apps , Games and Websites are huge. ALGOs are sloppy.
Nothing will happen until the bloat becomes visible again. This time it will take deliberate measurement of the problem and discipline to address it.
No, it doesn't slow down DEV work, coding takes place elsewhere.
Shockingly(sarcasm), we've caught many resource issues, eg poor code, poor schema, lack of indexes or db optimization, before they hid prod and become disaster.
AWS is hellish expensive, having a bill 10x what it could be is suboptimal. And the best way to prevent that, is resource constraints from day 1.
If you are trying to optimize for this goal, does it really matter if your software is as effective as it's physically possible?
There's a certain threshold for performance your customers implicitly expect you to reach. If you're within this boundary, is it really worth to spend days coming up with a new inverse square root optimization instead of bringing more value to your customer with new features?
I've spent time optimizing code in the past (mostly python) and its not hard to speed things up a lot. It feels at times though that the ecosystem is working against you.
Tools like electron encourage you to ship many many times more download size than is needed. Python loops speeds are getting better, but they've historically been insanely slow.
I don't think we need to individually obsess over speed, but as an industry we need to give people the tools so that code is performing by default. I think we're moving away from that end.
Also, you will never get a bonus in proportion to the cost savings of an optimization.
How many times in your career has a PM agreed to make room in the backlog to prioritize performance work? It very rarely happens and the reason is that costumers rarely care. It's catnip for developers and I love doing it, but it's rarely something that matters enough
The dichotomy between upper management and ICs in the weeds doing the actual work is mind boggling at times. ICs would understand the spectrum, and desire to create baseline targets across the service for the best experience we could muster. Meanwhile management only cared whether the core funnel met a specific target and viewed all other efforts as a distractions of the bottom line.
This narrow minded thinking directly results in a subpar experience for customers. It's a shame too, because product quality is critical at this organization.
Millennia ago someone built the pyramids.
Centuries ago someone built castles.
Those weren’t built to sell.
Today when homes are built they often use cheaper materials. The builder just needs to get them sold.
Most software strikes me as closer to building a cheap house or strip mall, as opposed to something that needs to last for centuries.
This is similar to other elements, like households appliances. They now also seem less "reliable" than in the past, but take an old simple toaster, and it is probably a fire hazard.
* Buy once model. Trial + buy is best. Some YouTube videos of people using the software is often good enough. If you offer a free ad supported version, and a buy once to remove ads version I will almost always buy the no ads version.
* Local saves. If you want to sync with the cloud that's fine, but I want to do read/writes from my local device whenever possible.
* Local computation. I have fast chips, I don't mind using them.
* Privacy. Do your competitors track me but you don't? Let me know.
* Modifiable appearance. I really put value in being able to change fonts and colors. I think this is a bit niche.
The main problem is that we are okay with shipping unfinished barely-beta software because we can always force the upgrade/update/change. You didn't have that luxury when you were shipping software on a floppy disk/CD-ROM, and that was it: all the bugs and issues were there, forever.
- I want to select a bit of text in Microsoft Teams (yeah, I know - it's not my choice), and as I move the cursor to the desired line, it moves over the line below, which causes a context menu to pop-up, which obscures the text I'm trying to select, so... swear, back off, and try again more carefully.
- I switch applications on macOS with the command-tab keys, but I'm also anticipating where I want the mouse to be, so I start moving the mouse too. Sometimes, the mouse moves over the row of icons, which changes the selected icon, and I end up in a different app to the one I want.
The way to break a loop is to target audience with lower lag-tolerance. Once the user experiences fast product it'll be annoying to use everything else.
The question which is the lede maybe states it better than the title which precedes it: "With all the advancements in software development, apps could be much better. Why aren't they?"
On that basis I think the article is ok although I didn't vote it up.
About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much) An operating system had to manage with 8,000 bytes, and compiler had to fit into 32 Kbytes, whereas their modern descendants require megabytes. Has all this inflated software become any faster? On the contrary. Were it not for a thousand times faster hardware, modern software would be utterly unusable.edit: Thank you for jogging my memory. I was serious.
But that old software is swamped by new software - web pages in particular, but also IoT, Tesla self driving, smart TV's, Max 737's, my robot vacuum and my step daughters desk (it refuses to go up unless you reset it). As predicted software is indeed eating the world, so new software is everywhere. A day doesn't go by without me having to work around the deficiencies of some piece of crap.
So you could be forgiven for thinking that software is getting worse if all you are doing is comparing mature software to new stuff. But remember a long time ago (well not that long, as I was a programmer back then too), that mature software was just a new and unreliable as todays new software. With very rare exceptions like the space shuttle software (because it requires a metric f*k ton of money to get bugs per loc in new software down to 5 or 6 nines), all new software is shit.
If the customers of the software written today cared about quality -- and they _should_ care about quality -- they'd demand a higher standard of quality for the money they are paying.
They don't, though. Firstly, the users aren't the customers. The customers are the advertisers or corporate buyers. Secondly, the users don't _want_ to be customers. They'd rather whatever they can get for free that anything that costs money, even if the thing that costs money could be orders of magnitude better.
The first thought I have: I think quality is inclusive of size, speed, and reliability. Quality is _also_ features and functionality. It is also user experience. Probably many other things too, but this is just off the top of my head.
I'm also not sure users would come rushing to the side of programmers if _they_ became the customers.
I am the customer of companies that make many other things in my life. The quality probably isn't what it could be if that consideration was put much more front and center. For many things, I am _fine_ with that.
For the same reasons, I don't think the users of software would be obviously wrong. Certainly I don't think they're obviously wrong enough for me to become preachy. If writing software that isn't to the level of quality I demand or need causes me existential dread, I am now willing to say that might be a "me" problem.
The only part here that seems to be true in my experience is “using less experienced developers”.
I don’t see that apps are developed faster nor that they have more features than ever. Quite the contrary.
1993.
Slack is a resource optimization absurdity. But it serves its target users well as they have plenty of resources anyway.
Slowly but surely the pressure is building up to change the software.
https://news.ycombinator.com/item?id=34581303 January 2023, 41 comments
This works to the advantage of a handful of large tech companies. Google, Facebook/Meta, Twitter/X, Apple, Microsoft, and some Chinese companies like Tencent, have the scale and market position to give away at least some of their respective applications. They provide what the article describes as a "joyless revenue machine that exploits your users’ attention and privacy at every turn", and do so with sufficient volume and market dominance to be profitable.
In a world where almost anyone can whip up an app, the inability to charge for it, and difficulty of growing large enough to profit off user attention and data, acts as a barrier to entry.
I will end my cynical rant here.
I do agree with your rant in principle and doubly so with chat clients.
Probably because reducing RAM usage has even less potential than a feature nobody uses. Someone might use a feature, so you can take a risk on it. Who (who might otherwise buy Slack) wouldn't buy Slack because it uses 1-2 gigs of RAM?
This is not really my experience. Most devs within a corporate structure are lazy and will do the bare minimum.
I’ve repeatedly seen absolutely terrible developers who ship rapidly praised over developers who are skilled and deliberate.
I think it’s even more complicated than that but I agree many developers don’t care or don’t know better, but that’s true of any job.
Software is like sex. Good requires effort. You have every right to demand money for it but not many people will appreciate it if you do. On the other hand if you use it skillfully you can use it to take oh so much of people's money.
My one remaining windows machine seems like its always spun up doing something in the background, and I'm skeptical that it's for my benefit.
Baloney. The market is a collection of people. I am a person and I care. The next time someone foists junk on you tell them it is junk. Show them a better way. For example, I had a displeasure of using Teams to communicate with some contractors recently. I had not used Teams in a while but knowing MS well I knew just what to expect, and I was not disappointed. Getting onboarded and authenticated was like pulling teeth, and when I joined a meeting with my speakers the participants complained that I was causing an echo. They did not know that that echo cancellation, as implemented by any tool for fit for the job, was not active. Nobody thought to ask "Huh, that's strange, we don't have this problem with Meet or Zoom." This is not something users should have to think about or configure in 2023.
It comes down to recognizing junk, caring that it is junk, and having the option to choose something better.
The ones holding the purse strings have the power. That’s rarely developers.
We have games that run really well and are responsive, since that's where it matters. We can still do it, it just doesn't matter to anyone most of the time but developers who enjoy performance optimization (like I do!)
2. Start by blaming yourself, then blame others. Can you proove to your manager why spending a week on performance tuning is the best use of your time? If you can, they will let you do it. If you cannot, it is your fault or even maybe your mistake for thinking optimising your app's performance is a good idea.
3. A very good chunk of developers dont even know how to measure performance, let alone tune.
4. If technical debt is becoming a problem it is your responsibility to fix it as part of your next boud of code. Did your manager ask for feature X? Tell them it takes Y amount of time and bake in a slight refactor around X that will.make your software better. Dont even ask them, or let them know. Every feature will come with some slight tech debt resolution.
5. The economic issue of software is not a problem of what people percieve being worth paying for. The economic problem is software's inherent incompatibility with the capitalist market functionality. The history of software's monetization is the history of buisnesses desperately trying to hack around this core incompatibility - which we haven't fully realized yet.
Single Platform Native Code is Easier than ever:
In the 1990s, you could write a CRUD program in a few hours in VB6, Access, or Delphi back in the 1990s. It would run on most computers worldwide, and was likely small enough to fit on a 1.4 Mb Floppy Disk, with help files, an installer, and everything.
This is the software model that the Internet is optimized to deliver. Native code, direct from a programmer. It still works in many cases. GitHub has even made it easier than ever.
However, this is not the model the "market" has been pushed into.
--
The app store - a horrible compromise
If you can stomach the restrictions, you can still write native code, subject to review and restrictions, to be deployed through an "App Store".
I've never done this, but I do know that many things just don't align with their business model.
So, if you're going down this route, you have to price your software, and meet the arbitrary restrictions of the walled garden it's going to serve. You will, at least, be able to run native code directly on the device, so that's nice.
However, when the owners of the garden change their mind, your program may disappear, or you may be forced into changes that are otherwise unacceptable
--
The web - a descent into madness
If you're unfortunate enough to not be able to write native code, directly deployed, the environments in which software is expected to work have become abysmal. For you, it was unavoidable that things got orders of magnitude worse.
Now, you're expected to put the interface of a program through the internet into a web browser that might be on a desktop, laptop, tablet, or smartphone, or even perhaps a smartwatch.
There's no consistent interface. Thanks to a lack of secure general purpose computing, nobody is willing, nor should they be, to run code from somewhere else, unless it's from an "app store".
--
I don't see things getting better for another decade or so. Eventually a consistent set of GUI widgets and interfaces will be found, and a consensus will be reached about how things should act on a Desktop vs Tablet vs Watch, etc.
The shift to open source software was a great advance, but the shift to installing/downloading dependencies from the internet at install time was a horrible choice. There needs to be a way to lock all dependencies, "security" be damned. You should be able to run programs written a decade ago without having to rewrite it to adapt to all the breaking changes that seem to be so quick to happen in Open source.
Security is part of the OS, and any application libraries shouldn't be able to make the situation worse. Only capability based Operating Systems can resolve that dilemma.