Oracle Database has now been renamed Oracle AI Database. But I think that in time, they will rename it back to Oracle Database. The hype will pass, but the AI will remain, and the name will no longer need to include the AI prefix. AI will just become the norm.
We need something similar to the Svalbard Global Seed Vault, to protect un-AI'd Linux distributions so that, in the event of an AI apocalypse, we will have access to clean operating systems.
When chatGPT first gained traction I imagined a future where I'm writing code using an agent, but spending most of my time trying to convince it that the code I want to write is indeed moral and not doing anything that's forbidden by it's creators.
I built a spotify music extractor called harmoni that helps you download your playlists and I feel I'm done. It does its job and it caters to both non-technicals and technical people alike.
>Ignore feature requests — don't build what users ask for; understand the underlying problem instead
not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game).
for years and years, the reply from blizzard was "you think you want that, but you dont. trust us, you dont want that."
they eventually caved and launched classic WoW to overwhelming success. some time later, in an interview, ion hazzikostas (the game director) and holly longdale (vice president & executive producer), admitted that they got WoW classic very wrong and that the people "really did know what they want".
anyways, point being that sometimes the person putting in the feature request knows exactly what they want and they have a good idea. while your default mode might be (and perhaps should be) to ignore feature requests, it is worth recognizing that you may be doing so at your own loss. after all, you might not not be able to fully understand every underlying problem of every user of your product -- but you might understand how to code the feature that they asked for.
Well to me it sounded like they followed the first part (ignore feature requests) and failed at the second part.
Just build the feature is the wrong lesson to learn. The right lesson is to expend more effort to understand; and yes, part of that _could_ involve shipping the feature in order to get data/feedback.
Speaking of classic WoW... found this gem recently where a guy talks about his experience playing classic in 2026 without any nostalgia: https://www.youtube.com/watch?v=NjQgoaagS-E TLDR classic is pretty damn good!
>Ignore feature requests — don't build what users ask for; understand the underlying problem instead
That sounds like good advice on the surface but it should be "understand what the user is asking for" then see if it is a valid thing, after which you can decide how to accomplish it. Users usually come to you with the last bit. They ask you to do it in a particular way.
There is no cookie-cutter approach to all software products at once.
"I want classic sound / look / feel" of entertainment products like WoW is very different from, say, "I want old spreadsheet shortcuts / simpler UI" of office products where you have to actually balance many functional features that are in demand with simplicity and past product behaviour some of your users got used to.
Edit: I think I just rubber ducked myself with this comment into understanding that it is user segmentation which is key regardless of your product; real challenge is to try embedding and balancing all product features as a single package, instead of splitting core product into multiple different parts that fit different segments (like Blizzard did)
This is why I love Sublime Text. It's so fast, it works so well. It isn't trying to be AI, it isn't trying to evolve until it can read email or issue SSL certs via ACME. It's focused on one thing and it does it extremely, extremely well.
It's not about software, it's about money. They're chasing what they see making money and being mimetic. Simple as. It's a shame and sad to see so many get caught up in this, but it makes sense relative to where the world is at. People are desperate and this is what desperation manifest looks like.
Definitely that, a finite scope is good and finished software is beautiful.
But also, most of the modern software is in what I call "eternal beta". The assumption that your users always have an internet connection creates a perverse incentive structure where "you can always ship an update", and in most cases there's one singular stream of updates so new features (that no one asked for btw) and bug fixes can't be decoupled. In case of web services like YouTube you don't get to choose the version you use at all.
The issue is that a finite scope is paid once (and often pirated, so not even that), while subscription SaaS are paid perpetually, so there's more money there.
We should have a system where we continue paying for software that we keep using even if it doesn't change, but that's never going to happen, we will start wondering how we will replace it and cut costs.
The more stars my personal GitHub repos have, the more likely the project was something I cranked out over a weekend to scratch an itch, and then more or less abandoned because it was good enough -- maybe even perfect for that specific itch?
We should normalize "finished" software products that stop feature creep and focus strictly on bug fixes and security updates.
It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand.
Evernote and Dropbox were perfect in 2012. Adding more features just to chase new user growth often comes at the expense of confusing the existing user base. Not good
I wrote my comment before I read yours, but it perfectly explains why software doesn't do that. Sadly I can't take credit for the core idea: https://news.ycombinator.com/item?id=47272024
It's the wonderful part about OSS and 'mission-driven' projects. If the mission is not to make money, then a project is free to reject addons/etc that might be lucrative but not add value to the core of the product
I think notepad.exe is the strongest example of this right now.
The amount of hacking required to even be allowed to re-associate text files with that particular exe on Win11 was shocking to me. I get that windows is extremely hostile to its users as a general policy, but this one felt extra special.
I notice at this time there are no comments about systemd. I figured there would be at least one comment about it and "it does not try to do everything".
It grows and grows and eventually slows or grows too much and dies (cancer), but kinda sheds its top-heavy structure as its regrown anew from the best parts that survived the balanced cancer of growth?
Just forks and forks and restarts. It's not the individual piece of softwares job (or its community's) to manage growing in the larger sense, just to eventually leave and pass on its best parts to the next thing
Just like all organizations are naturally self-expanding and self-perpetuating. Same with all organizations building software. The natural pressure is to expand. It is hard to resist it.
73 comments
[ 2.3 ms ] story [ 60.5 ms ] threadWhen chatGPT first gained traction I imagined a future where I'm writing code using an agent, but spending most of my time trying to convince it that the code I want to write is indeed moral and not doing anything that's forbidden by it's creators.
not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game).
for years and years, the reply from blizzard was "you think you want that, but you dont. trust us, you dont want that."
they eventually caved and launched classic WoW to overwhelming success. some time later, in an interview, ion hazzikostas (the game director) and holly longdale (vice president & executive producer), admitted that they got WoW classic very wrong and that the people "really did know what they want".
anyways, point being that sometimes the person putting in the feature request knows exactly what they want and they have a good idea. while your default mode might be (and perhaps should be) to ignore feature requests, it is worth recognizing that you may be doing so at your own loss. after all, you might not not be able to fully understand every underlying problem of every user of your product -- but you might understand how to code the feature that they asked for.
Just build the feature is the wrong lesson to learn. The right lesson is to expend more effort to understand; and yes, part of that _could_ involve shipping the feature in order to get data/feedback.
And the people owning the product were convinced players wanted more features.
That sounds like good advice on the surface but it should be "understand what the user is asking for" then see if it is a valid thing, after which you can decide how to accomplish it. Users usually come to you with the last bit. They ask you to do it in a particular way.
You can't really map b2b enterprise software tropes onto b2c entertainment products, as ActiBlizz would discover.
"I want classic sound / look / feel" of entertainment products like WoW is very different from, say, "I want old spreadsheet shortcuts / simpler UI" of office products where you have to actually balance many functional features that are in demand with simplicity and past product behaviour some of your users got used to.
Edit: I think I just rubber ducked myself with this comment into understanding that it is user segmentation which is key regardless of your product; real challenge is to try embedding and balancing all product features as a single package, instead of splitting core product into multiple different parts that fit different segments (like Blizzard did)
Yeah...
is to begin naming;
when names proliferate
it’s time to stop.
If you know when to stop
you’re in no danger."
But also, most of the modern software is in what I call "eternal beta". The assumption that your users always have an internet connection creates a perverse incentive structure where "you can always ship an update", and in most cases there's one singular stream of updates so new features (that no one asked for btw) and bug fixes can't be decoupled. In case of web services like YouTube you don't get to choose the version you use at all.
We should have a system where we continue paying for software that we keep using even if it doesn't change, but that's never going to happen, we will start wondering how we will replace it and cut costs.
It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand.
Evernote and Dropbox were perfect in 2012. Adding more features just to chase new user growth often comes at the expense of confusing the existing user base. Not good
It is "their" distribution, to do with as they wish. If this would happen to your workstation, you are a fool, for not following release notes.
I already jumped distros for several reasons, marketing BS was one of them. I do not need latest scam or flag of the month!
The amount of hacking required to even be allowed to re-associate text files with that particular exe on Win11 was shocking to me. I get that windows is extremely hostile to its users as a general policy, but this one felt extra special.
It grows and grows and eventually slows or grows too much and dies (cancer), but kinda sheds its top-heavy structure as its regrown anew from the best parts that survived the balanced cancer of growth?
Just forks and forks and restarts. It's not the individual piece of softwares job (or its community's) to manage growing in the larger sense, just to eventually leave and pass on its best parts to the next thing