> discontinued: Atom just got discontinued. It's open source. Photoshop on the other hand has withstood the test of time.
But if I want to use Atom I can fork it, or keep the source around. It doesn't go away from my environment until _I_ say it does. And Photoshop has become more and more user hostile over time.
> Audacity's 3.0 update removed a feature I relied on. I wasn't forced to update to it, sure, but proprietary software doesn't force updates either.
It is impossible for libre software to force updates, and quite possible for proprietary software to do so. It's part of what pushed me away from Windows in the first place, and other apps (especially web, but also other stuff) also do so.
> Being able to fix your own bugs is a great part of open source! But not something most professional software developers really expect to do for their IDE.
While it isn't expected, it's definitely a nice-to-have.
> open source formats are probably more resilient than closed source, but I would argue many proprietary formats are also pretty resilient. Code is also based on plain text at it's core, like latex, so it's always going to be pretty resilient.
But with libre software, I don't have to wonder. Even if a project uses an obtuse, obfuscated binary format I know I'll still be able to read it (with a little prep work). With code this is less of an issue - as you note - but you did mention Photoshop earlier, so I'm assuming we're talking about software in general.
> you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
I don't need it to he leading, I need it to be around and functional. Pretty confident Emacs/(n)vim will be here a couple decades longer at least. I believe this was GP's point - that it's better to worry about what will work best in 10 years, not what's standard now.
> But if I want to use Atom I can fork it, or keep the source around. It doesn't go away from my environment until _I_ say it does.
This is technically true, but in 99% of the cases is not realistically true. Most developers who use said FOSS external dependency do not want to actively maintain it themselves.
FOSS supporters always say this as if we live in a reality where knowledge and time are infinite. Yes, the licenses say you can legally do things, but they are hardly ever realistic.
Well, you don't do the maintenance yourself, you get some bored person to do it-- the important thing is they're not on a payroll and the result isn't someone's IP. Right now this strategy probably seems insane, because we are all so well compensated that the opportunity cost of working on OSS for free is massive, but sometimes you get 'lucky' and a software downturn frees up some engineering hours for further pro bono work on OSS. Pretty sure that has happened several times already, might happen again soon.
It's a bit like saying 'let them fly on private jets' and someone pointing out that only a few people in the population can afford it. Doesn't imply that private jets are useless, just that their use is limited.
Anyone with access to a computer (a prerequisite to use software in this context in the first place[0]), also has access to the tools to learn to perform these actions.
Pretty sure most people don't have the ability to teach themselves to fly a private jet and then walk up and take off.
[0] Setting aside phones/mobile. Yes they exist, yes they're important. No they're not relevant to this thread.
Ah yes. I have the time and the knowledge to "just" remove that code and "just" build that version. When even the simplest libraries can't usually be built using the instructions the authors leave for them (if they even do that)
You don't have to remove the code, you can just pin the version you're using and go for quite some time (sensitive to security context). Most builds are pretty easy to do with 5 minutes of following instructions or whatever build tool. I did this exactly thing with termux (an app I relied on) when they removed sending sms due to a google rule change.
Also, you only have to do it if you're the only one left. Chances are very good that there are others in the community that may step up wholly or in part. Sure the risk is non-zero, but the point of freedom is that you could if it came to that.
I think Gnome / GTK is a good example. Famously, the Budgie Desktop Environment will have to be rewritten on top of Enlightenment because they don't like the GTK 4 changes. So now they're forced to go to a different widget system. [1]
Your use of "forced" is interesting, because to me that doesn't sound like "force" at all, rather a "we don't like this thing so we're moving" which is a free choice for technical reasons.
Force to me is like what Amazon does with kindles. If it connects to the internet, it will update to the latest version whether you want it to or not. If you don't connect it to the internet, you can't use it.
But if I want to use Atom I can fork it, or keep the source around. It doesn't go away from my environment until _I_ say it does. And Photoshop has become more and more user hostile over time.
> Audacity's 3.0 update removed a feature I relied on. I wasn't forced to update to it, sure, but proprietary software doesn't force updates either.
It is impossible for libre software to force updates, and quite possible for proprietary software to do so. It's part of what pushed me away from Windows in the first place, and other apps (especially web, but also other stuff) also do so.
> Being able to fix your own bugs is a great part of open source! But not something most professional software developers really expect to do for their IDE.
While it isn't expected, it's definitely a nice-to-have.
> open source formats are probably more resilient than closed source, but I would argue many proprietary formats are also pretty resilient. Code is also based on plain text at it's core, like latex, so it's always going to be pretty resilient.
But with libre software, I don't have to wonder. Even if a project uses an obtuse, obfuscated binary format I know I'll still be able to read it (with a little prep work). With code this is less of an issue - as you note - but you did mention Photoshop earlier, so I'm assuming we're talking about software in general.
> you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
I don't need it to he leading, I need it to be around and functional. Pretty confident Emacs/(n)vim will be here a couple decades longer at least. I believe this was GP's point - that it's better to worry about what will work best in 10 years, not what's standard now.