I’m switching from VS Code to VS Codium(ruky.me)
ruky.me
I’m switching from VS Code to VS Codium
https://ruky.me/2022/06/11/im-switching-form-vs-code-to-vs-codium/
340 comments
Paying for software does not have a relationship with quality. Imagine if GCC had a "pro" version that was necessary to compile certain code. That would be devastating to those learning and thousands of devs that came before would be spinning in their graves.
The reason we do open source and free software is to make life easier for everyone, including your job. It standardizes practices and prevents mudball codebases comprised of black box libraries and tools.
Not to mention that selling of extensions is like selling of game mods. There's tons of stolen code.
The reason we do open source and free software is to make life easier for everyone, including your job. It standardizes practices and prevents mudball codebases comprised of black box libraries and tools.
Not to mention that selling of extensions is like selling of game mods. There's tons of stolen code.
> The reason we do open source and free software is to make life easier for everyone, including your job. It standardizes practices and prevents mudball codebases comprised of black box libraries and tools.
No, it is to maintain control. If you grow to depend on non-free software, you are at the mercy of its authors. Any benefits to quality are incidental.
No, it is to maintain control. If you grow to depend on non-free software, you are at the mercy of its authors. Any benefits to quality are incidental.
>Paying for software does not have a relationship with quality.
I'm taking "paying for software" here to mean "commercial" vs "open source", or "incoming money oriented" vs "community building oriented" development.
Since, of course, you can also pay for open source, and there are free editions of proprietary commercial software, and foss can be sponsored by a big company who pays for 99% of the developer time through selling something else - so a distinction based on "paying" alone is not useful.
So, does open source/free vs proprietary/commercial make any difference with regards to quality?
It might not make in abstract, across the whole market, but in certain aspects and markets it does.
No open source DAW (audio/midi editor) or NLE (video editor) is even close to commercial ones, for example.
If you plotted features, maturity, stability, performance, etc. for foss and commercial versions of this types of product, you'd see a clear clustering of proprietary commercial software where you pay a lot for and free foss ones.
The same is true for many pro fields.
I'm taking "paying for software" here to mean "commercial" vs "open source", or "incoming money oriented" vs "community building oriented" development.
Since, of course, you can also pay for open source, and there are free editions of proprietary commercial software, and foss can be sponsored by a big company who pays for 99% of the developer time through selling something else - so a distinction based on "paying" alone is not useful.
So, does open source/free vs proprietary/commercial make any difference with regards to quality?
It might not make in abstract, across the whole market, but in certain aspects and markets it does.
No open source DAW (audio/midi editor) or NLE (video editor) is even close to commercial ones, for example.
If you plotted features, maturity, stability, performance, etc. for foss and commercial versions of this types of product, you'd see a clear clustering of proprietary commercial software where you pay a lot for and free foss ones.
The same is true for many pro fields.
I think you're forgetting that the people who work on GCC are usually paid to do so, and their work is funded by people buying software built with GCC.
It definitely has a relationship with quality in a fair number of domains. Find me free CAD software as good as SOLIDWORKS, or free maths software as good as MATLAB & Mathematica, or free EDA software as good as Altium or Vivado.
There are loads of domains where none of the free options are very good.
There are loads of domains where none of the free options are very good.
I agree with you for the most part, I write this while running Matlab simulations in the background. Having tried to reach similar levels of productivity with Julia or Python, I find the FOSS environments always fall short in the tooling environment. Not to mention the importance of documentation.
However, I can't help but take exception to Vivado and SOLIDWORKS being good software... While powerful, they are both incredibly buggy and prone to crashing if you so much as look at them wrong.
However, I can't help but take exception to Vivado and SOLIDWORKS being good software... While powerful, they are both incredibly buggy and prone to crashing if you so much as look at them wrong.
The only use case I can think where matlab beats Python or Julia is when one has a lot of legacy code. It's funny that you mention documentation, the amount of documentation found around Python is typically much better than matlab. Matlab toolboxes are really hit and miss, some are very good, but there are some really crappy ones. If you actually need to include more traditional programming features matlab becomes a hot mess. Looking at matlab GUI code gives me nightmares for weeks....
I would not wish Matlab GUI programming on my worst enemy.
I disagree with your assertion that documentation for Python is typically much better. Take a randomly chosen function I regularly use: "pwelch"
https://docs.scipy.org/doc/scipy/reference/generated/scipy.s...
https://www.mathworks.com/help/signal/ref/pwelch.html
Maybe my bias is showing, but I find the Matlab documentation to be superior. However, that is nothing compared the quality of the IDE which is critical when doing scientific compute. When I was re-evaluating our simulation environment at work, we looked at PyCharm. The plotting capabilities alone made it easy to stick with Matlab, even at the orders of magnitude higher cost.
N.B. This is my experience in an Optical Communications R&D environment.
https://docs.scipy.org/doc/scipy/reference/generated/scipy.s...
https://www.mathworks.com/help/signal/ref/pwelch.html
Maybe my bias is showing, but I find the Matlab documentation to be superior. However, that is nothing compared the quality of the IDE which is critical when doing scientific compute. When I was re-evaluating our simulation environment at work, we looked at PyCharm. The plotting capabilities alone made it easy to stick with Matlab, even at the orders of magnitude higher cost.
N.B. This is my experience in an Optical Communications R&D environment.
Funny I'm in optical comms as well, chances are we know each other. I never used "pwelch" though. But I concur my statement on documentation was too strong, I guess it depends quite a bit.
Regarding IDE, I guess we tend to put priorities on different things. I find pycharm's (pro edition) git Integration, debugging, refactoring and profiling vastly superior. I plot using regular qt windows and I agree that for interactive plots where one wants to look at points etc, matlab has the edge, for publication ready plots matplotlib beats matlab hands down though (although the API is quite verbose, proplotlib is a wrapper that makes things more convenient IMO).
Anyway I think we have different priorities in what we are looking for. We use Python for labautomation and the matlab instrumentation toolbox is a buggy mess, our measurement times decreased by a factor of 5-10 when we switched from matlab.
Regarding cost, we are a university so matlab and python have equal costs. I do know of colleagues at industry labs where matlab cost was a factor though.
Regarding IDE, I guess we tend to put priorities on different things. I find pycharm's (pro edition) git Integration, debugging, refactoring and profiling vastly superior. I plot using regular qt windows and I agree that for interactive plots where one wants to look at points etc, matlab has the edge, for publication ready plots matplotlib beats matlab hands down though (although the API is quite verbose, proplotlib is a wrapper that makes things more convenient IMO).
Anyway I think we have different priorities in what we are looking for. We use Python for labautomation and the matlab instrumentation toolbox is a buggy mess, our measurement times decreased by a factor of 5-10 when we switched from matlab.
Regarding cost, we are a university so matlab and python have equal costs. I do know of colleagues at industry labs where matlab cost was a factor though.
> However, I can't help but take exception to Vivado and SOLIDWORKS being good software... While powerful, they are both incredibly buggy and prone to crashing if you so much as look at them wrong.
That hasn't been my experience. Solidworks definitely isn't as responsive as I'd like, but frankly I'll take "a bit sluggish but has all the major features and is not a UX disaster" over something like FreeCAD or Yosys.
That hasn't been my experience. Solidworks definitely isn't as responsive as I'd like, but frankly I'll take "a bit sluggish but has all the major features and is not a UX disaster" over something like FreeCAD or Yosys.
You might be right in cad and eda, but there's surely a case to be made that python libs(numpy, sympy), sage, r, octave could be better that matlab or mathematica.
I've used Numpy, Matplotlib, Octave and Scilab. None of them are really anywhere as good as Matlab. R has quite a different focus.
The biggest thing Matlab has is the GUI (which is surprisingly good!), the documentation (excellent), and the plot viewer. The plot viewer is probably its killer feature. There's just nothing remotely as good in any other software, at least as far as I could find.
Octave's is terrible. Barely any features and incredibly slow.
The biggest thing Matlab has is the GUI (which is surprisingly good!), the documentation (excellent), and the plot viewer. The plot viewer is probably its killer feature. There's just nothing remotely as good in any other software, at least as far as I could find.
Octave's is terrible. Barely any features and incredibly slow.
Calling GCC a "good" compiler is going a bit far, imo. LLVM has become the dominant compiler framework (and thus clang, clang++, golang, etc use it) because of corporate interests.
GCC as it's constructed is a horrible framework. The way you port GCC to a new platform (say, a weird ARM variant) is to fork it hard and mangle multiple parts of the internals, then carefully feed it back. It's a mess. Nobody should be forced to port GCC.
The reason LLVM is good is because it has a corporate back (Apple, Google, IBM, ARM, Intel, Synopsys, NVIDIA, AMD, etc: https://foundation.llvm.org/docs/sponsors/) and it has a lot of work put into it to make extensible (which GCC isn't by design) and as a result have a clean interface for usage.
On the other side of this argument, paid extensions (and paid code in general) exists because at one point or another we live in a society run on capitalism. Unfortunately, that means that money has to come from somewhere to make bread hit the table. For a lot of open source, that money comes from one of two places:
* Corporations (people doing work on open source projects under the auspices of their company)
* Donations (people saying "this open source is good enough I want to make it continue happening").
One is sustained by maintaining the tools you use. The other is sustained by grace.
GCC as it's constructed is a horrible framework. The way you port GCC to a new platform (say, a weird ARM variant) is to fork it hard and mangle multiple parts of the internals, then carefully feed it back. It's a mess. Nobody should be forced to port GCC.
The reason LLVM is good is because it has a corporate back (Apple, Google, IBM, ARM, Intel, Synopsys, NVIDIA, AMD, etc: https://foundation.llvm.org/docs/sponsors/) and it has a lot of work put into it to make extensible (which GCC isn't by design) and as a result have a clean interface for usage.
On the other side of this argument, paid extensions (and paid code in general) exists because at one point or another we live in a society run on capitalism. Unfortunately, that means that money has to come from somewhere to make bread hit the table. For a lot of open source, that money comes from one of two places:
* Corporations (people doing work on open source projects under the auspices of their company)
* Donations (people saying "this open source is good enough I want to make it continue happening").
One is sustained by maintaining the tools you use. The other is sustained by grace.
> For a lot of open source, that money comes from one of two places:
You missed a third place: government funding. Ironic, given that LLVM itself started as a University of Illinois research project. Private interests love taking credit for publicly-funded research:
https://www.theguardian.com/science/2021/apr/15/oxfordastraz...
You missed a third place: government funding. Ironic, given that LLVM itself started as a University of Illinois research project. Private interests love taking credit for publicly-funded research:
https://www.theguardian.com/science/2021/apr/15/oxfordastraz...
Generally speaking, commercial software gives more guarantees than free software, because free software writers have no obligations. Of course, there's no absolute certainty.
Right now I'm stuck with an old version of a certain software, because the extensions are free, but some of the authors are not upgrading them anymore. If the extensions were commercial, I'd be happily paying, if that would give the extensions a longer lifetime.
Having somebody working on an extension at least a part of their time, because it represents a source of income, surely makes a difference.
Again, VSC's Ruby extension sucks big time. If there was a company behind, with a paid developer, like in IntelliJ's case, it would certainly have a different quality.
Right now I'm stuck with an old version of a certain software, because the extensions are free, but some of the authors are not upgrading them anymore. If the extensions were commercial, I'd be happily paying, if that would give the extensions a longer lifetime.
Having somebody working on an extension at least a part of their time, because it represents a source of income, surely makes a difference.
Again, VSC's Ruby extension sucks big time. If there was a company behind, with a paid developer, like in IntelliJ's case, it would certainly have a different quality.
> I was increasingly getting upset about their extension marketplace, where there is an increased number of extensions starting to sell pro versions of the extensions we used for free.
So, "I'm a professional developer, but I don't like other programmers getting paid for their extensions (that I do, nonetheless, find valuable, and want to use)"?
So, "I'm a professional developer, but I don't like other programmers getting paid for their extensions (that I do, nonetheless, find valuable, and want to use)"?
I love this developer dissonance where they work at companies selling software, but refuse to pay for others’ software.
Truly a sight to behold!
Truly a sight to behold!
It makes sense for an artist creating underground work, and not getting paid for it (e.g. actually illegal graphitti artist, or some avant guarde type that works a different day job and doesn't want to "sell out" to galleries) to be against the commercialization of art.
But for programmers living off programming? Less so.
But for programmers living off programming? Less so.
I know of two director level folks (they were promoted from being devs, but not geeky enough to read HN or dev blogs) who would repeatedly use 'open source' only as a full synonym for 'free of charge' in multiple conversations about tools and paying for them. For example when comparing software, "we need to pay for X but Y is open source".
Are you trying to repeat Bill Gates's Open Letter TO Hobbyists?
You're still missing "Most directly, the thing you do is theft."
I think the past 46 years have proved, that free software works, no matter how many Bills want (or will) get rich off the industry. If there were no hobbyists either literally stealing software, or indirectly "stealing" it, because it's free, there would be no industry to profit from.
You're still missing "Most directly, the thing you do is theft."
I think the past 46 years have proved, that free software works, no matter how many Bills want (or will) get rich off the industry. If there were no hobbyists either literally stealing software, or indirectly "stealing" it, because it's free, there would be no industry to profit from.
As Heartbleed and numerous other examples show, the corporations freeload and then barely give anything back. There should be a nuanced middle ground between charging everyone for everything and not letting corporations that collectively make hundreds of billions if not more of revenue off software get away with contributing nothing back.
[deleted]
reminds me when Bethesda tried to introduce paid mods on Steam. I was greatly excited about that for the reasons you state.
But the gaming community being physically or mentally at an age of 14 prevented that with quite an outreach.
Would've thought someone with enough braincells to learn programming would look at this differently, but there you have it.
But the gaming community being physically or mentally at an age of 14 prevented that with quite an outreach.
Would've thought someone with enough braincells to learn programming would look at this differently, but there you have it.
Theft. That's the reason. People could upload others mods to be paid. Or they would use assets they were not allowed to sell. The cost of litigating this is far too high, therefore a system that allows the theft cannot be regulated civilly. Meaning the system should not exist.
Mods work better in an open and free environment that lacks monetary incentives.
Mods work better in an open and free environment that lacks monetary incentives.
We can't figure out how to protect content creators so they should just do work for free seems like a cop out to me.
Or maybe they know the cost and it isn't worth it to them? The poster you respond to mentions litigation. That's how IP theft is handled. How much legal fees does anyone want to incur for due diligence or litigation or defense for mods and plug-ins.
Only the top few will earn enough to justify the effort. Everything under that will be left to fester. Quality free and low cost mods will get copied and promoted to scam money and the people working hard, that you and I both wish to help and support, would get no help or compensation.
Wasn't that mostly about Bethesda/Steam trying to capture the mod market and skim a percentage off of every transaction? Probably taking a page out of the iOS playbook.
If I have ever learnt something on tech related forums, it's that everything becomes magically okay when Apple does it and the benefits outweigh the costs.
Your argument falls flat when faced with rich history of modding and hacking. So many incredible creations were labors of love. Plenty of them eventually became commercial products.
What I find truly bizarre is how many software engineers, who are aware of how much they earn and how long it really takes to make software, are so resistant to paying anything for tools that make their job easier and faster. It blows my mind.
Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way. For individual use, most of them are <$100/year.
In years past I saw this same struggle with IntelliJ vs Eclipse or even vim/emacs. The amount of time I saw people spend on tuning, fixing, tinkering, debugging and otherwise modifying their .vim or .emacs files or their various incompatible Eclipse plugins (eg famously there were 2 big big plugins for Eclipse at one point and neither of them completely worked). At least with vim/emacs it works over an SSH connection but Eclipse?
Why are so many resistant so other people earning a living particularly when the payoff (ie time-saved) is so easily quantifiable? And why do people who generally earn so much value their time so little?
Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way. For individual use, most of them are <$100/year.
In years past I saw this same struggle with IntelliJ vs Eclipse or even vim/emacs. The amount of time I saw people spend on tuning, fixing, tinkering, debugging and otherwise modifying their .vim or .emacs files or their various incompatible Eclipse plugins (eg famously there were 2 big big plugins for Eclipse at one point and neither of them completely worked). At least with vim/emacs it works over an SSH connection but Eclipse?
Why are so many resistant so other people earning a living particularly when the payoff (ie time-saved) is so easily quantifiable? And why do people who generally earn so much value their time so little?
I think most of us value our freedom more.
Most people don't think of it in terms of freedom, but freedom it is. With proprietary software:
- You don't know when it will disappear or be discontinued. Even your paid-for existing version stops working when the activation servers go down.
- You might be forced into an "upgrade" which breaks something you rely on
- That's not to mention issues like being able to fix bugs yourself, extend it, or understand it. I don't do this often directly, but something like being able to understand a file format my data is in or similar is common
I don't mind paying for things, but things need to be a lot better on other axes before this one becomes the most important.
My experience is that:
- Things I did decades ago are sometimes useful. Nearly 100% of the time, if this was in a proprietary system, it's gone or unusable. My LaTeX files still work.
- Companies switch between growth mode and cash cow mode. When this happens, the cost to me is almost always higher than the initial benefit over free.
- Which is better on other axes goes back-and-forth. An investment I make into a tool now doesn't mean it will be the leading tool in five years.
- Those sorts of long-term considerations are almost always more important than short-term technical stuff.
Most people don't think of it in terms of freedom, but freedom it is. With proprietary software:
- You don't know when it will disappear or be discontinued. Even your paid-for existing version stops working when the activation servers go down.
- You might be forced into an "upgrade" which breaks something you rely on
- That's not to mention issues like being able to fix bugs yourself, extend it, or understand it. I don't do this often directly, but something like being able to understand a file format my data is in or similar is common
I don't mind paying for things, but things need to be a lot better on other axes before this one becomes the most important.
My experience is that:
- Things I did decades ago are sometimes useful. Nearly 100% of the time, if this was in a proprietary system, it's gone or unusable. My LaTeX files still work.
- Companies switch between growth mode and cash cow mode. When this happens, the cost to me is almost always higher than the initial benefit over free.
- Which is better on other axes goes back-and-forth. An investment I make into a tool now doesn't mean it will be the leading tool in five years.
- Those sorts of long-term considerations are almost always more important than short-term technical stuff.
Most of your points also apply to open source software, and aren't strict requirements for proprietary software.
- discontinued: Atom just got discontinued. It's open source. Photoshop on the other hand has withstood the test of 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.
- 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.
- 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.
- you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
- discontinued: Atom just got discontinued. It's open source. Photoshop on the other hand has withstood the test of 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.
- 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.
- 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.
- you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
> 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. 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.
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.
For the atom case, it seems some users are going to continue to maintain it: https://github.com/atom-community/atom/
Might be more interesting to follow the next editor the author is working on.
https://zed.dev/
https://zed.dev/
“It is impossible for libre software to force updates”
This isn’t even close to being true
This isn’t even close to being true
If it did you'd just build a version with the offensive code removed?
If you have the skills.
The large majority of humanity does not
That's like saying that hardware should be only repairable by vendor because majority of humanity doesn't have skills to fix it themselves.
That's not even close to what they said.
They said, you can do it "if you have the skills" and that "the large majority of humanity does not" have these skills.
They said, you can do it "if you have the skills" and that "the large majority of humanity does not" have these skills.
That's literally what they've said. They imply that having ability to change something is useless, because only a minority can leverage it.
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.
Do you have access to private jet? Because everyone has access to, for instance, Atom source code. Even if they can't use it.
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.
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.
Maybe you don't, but somebody else does.
Any evidence to back that up?
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]
[1] https://joshuastrobl.com/2021/09/14/building-an-alternative-...
[1] https://joshuastrobl.com/2021/09/14/building-an-alternative-...
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.
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.
Its a technical decision. Nobody is forcing them to do anything.
Sure, that's a good example of something else, but do you have any examples of any forced updates?
> - discontinued: Atom just got discontinued. It's open source. Photoshop on the other hand has withstood the test of time.
If you like Atom and still want to use it, you can fix potential bugs yourself and make it evolve, you can't with a proprietary one. You can also fork if project take a different direction that you would like. When gnome3 came up, some people who preferred the gnome2 desktop metaphor started mate and cinnamon, the former forking gnome 2 to port it to gtk-3 while the later forked gnome3 to adapt it to work more like gnome2.
> - you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
Nobody has to use the leading tool. My preferred IDE is neovim which is kind of a niche project. While they are the leaders there is no reason for me to use Visual Studio or Visual Studio Code if I am not comfortable on them.
If you like Atom and still want to use it, you can fix potential bugs yourself and make it evolve, you can't with a proprietary one. You can also fork if project take a different direction that you would like. When gnome3 came up, some people who preferred the gnome2 desktop metaphor started mate and cinnamon, the former forking gnome 2 to port it to gtk-3 while the later forked gnome3 to adapt it to work more like gnome2.
> - you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
Nobody has to use the leading tool. My preferred IDE is neovim which is kind of a niche project. While they are the leaders there is no reason for me to use Visual Studio or Visual Studio Code if I am not comfortable on them.
> If you like Atom and still want to use it, you can fix potential bugs yourself and make it evolve...
If "you" is "a company or sponsored non-profit with sufficient development resources to dedicate some to taking over and evolving the editor," sure. If "you" is me, and I suspect 99.99% of Atom users, this seems like a pretty unrealistic ask.
This isn't a criticism of the open source model, to be clear, but this has always struck me as one of the weaker arguments for it having an advantage over closed source models. There are certainly examples of successful forks and revivals, but there are also examples of projects that never got sufficient uptake to continue when the original developer moved on (e.g., the Ted RTF-based word processor), and probably many more projects that just seem to exist in a kind of limbo state, technically still developed but not really seeming to put much effort into keeping up with the world -- off the top of my head, Unix's JOE and JED editors and the famous native Mac editor TextMate, which arguably inspired a raft of later editors including Visual Studio Code. And in practice, closed source projects that get a sufficient level of usage are likely to stick around and keep being developed, too. There are always exceptions, but usually if something continues to be sufficiently popular -- which, in the closed source world, is roughly equivalent to "profitable" -- it's going to keep being supported.
If "you" is "a company or sponsored non-profit with sufficient development resources to dedicate some to taking over and evolving the editor," sure. If "you" is me, and I suspect 99.99% of Atom users, this seems like a pretty unrealistic ask.
This isn't a criticism of the open source model, to be clear, but this has always struck me as one of the weaker arguments for it having an advantage over closed source models. There are certainly examples of successful forks and revivals, but there are also examples of projects that never got sufficient uptake to continue when the original developer moved on (e.g., the Ted RTF-based word processor), and probably many more projects that just seem to exist in a kind of limbo state, technically still developed but not really seeming to put much effort into keeping up with the world -- off the top of my head, Unix's JOE and JED editors and the famous native Mac editor TextMate, which arguably inspired a raft of later editors including Visual Studio Code. And in practice, closed source projects that get a sufficient level of usage are likely to stick around and keep being developed, too. There are always exceptions, but usually if something continues to be sufficiently popular -- which, in the closed source world, is roughly equivalent to "profitable" -- it's going to keep being supported.
> If "you" is "a company or sponsored non-profit with sufficient development resources to dedicate some to taking over and evolving the editor," sure. If "you" is me, and I suspect 99.99% of Atom users, this seems like a pretty unrealistic ask.
I've used several projects (mostly libraries) that got abandoned, and only two I had to adopt and maintain myself, and those were pretty low maintenance. If there is a community around it, somebody (who isn't you) might step up, so you don't have to do it.
I've used several projects (mostly libraries) that got abandoned, and only two I had to adopt and maintain myself, and those were pretty low maintenance. If there is a community around it, somebody (who isn't you) might step up, so you don't have to do it.
The original point was how much time and effort is spent to save a pittance in the grand scheme of things. You're confirming how much effort is spent by rich engineers not to pay money. I know there is a principle, but in the end it's still so much effort.
There is nowhere mention about money in that article.
> Most of your points also apply to open source software, and aren't strict requirements for proprietary software.
Except I can still use discontinued open source software like Atom.
Try installing an older version of an app on an old iPhone. The app store won't let you. You might be able to jailbreak the phone and track down an older version of the app, but it's a pain and Apple makes it as difficult as they can for you instead of just letting you download the version you want from their store.
Except I can still use discontinued open source software like Atom.
Try installing an older version of an app on an old iPhone. The app store won't let you. You might be able to jailbreak the phone and track down an older version of the app, but it's a pain and Apple makes it as difficult as they can for you instead of just letting you download the version you want from their store.
> Except I can still use discontinued open source software like Atom.
The same thing can be said about desktop proprietary software, so long as it does not rely on a cloud service to function.
> Try installing an older version of an app on an old iPhone. The app store won't let you. You might be able to jailbreak the phone and track down an older version of the app, but it's a pain and Apple makes it as difficult as they can for you instead of just letting you download the version you want from their store.
iOS is an extreme situation, but we are talking about desktop apps here, desktop OSes don't have these kinds of restrictions.
That said, open source have this edge that if it's just too obsolete for the dependencies, you can hope someone would patch it if it's popular enough. It would be harder to patch a proprietary app. That may not matter as much in the context of Electron apps as the web platform is pretty stable. Not sure about the Java thing Jetbrains IDEs are running on though.
The same thing can be said about desktop proprietary software, so long as it does not rely on a cloud service to function.
> Try installing an older version of an app on an old iPhone. The app store won't let you. You might be able to jailbreak the phone and track down an older version of the app, but it's a pain and Apple makes it as difficult as they can for you instead of just letting you download the version you want from their store.
iOS is an extreme situation, but we are talking about desktop apps here, desktop OSes don't have these kinds of restrictions.
That said, open source have this edge that if it's just too obsolete for the dependencies, you can hope someone would patch it if it's popular enough. It would be harder to patch a proprietary app. That may not matter as much in the context of Electron apps as the web platform is pretty stable. Not sure about the Java thing Jetbrains IDEs are running on though.
> That said, open source have this edge that if it's just too obsolete for the dependencies, you can hope someone would patch it if it's popular enough. It would be harder to patch a proprietary app.
IMHO this understates the difference, severely. The open source app can be maintained by the community for as long as it has a community. That includes not just dealing with dependency obsolescence but also new features, redesign, porting to new platforms… anything that would have been handled by the original team.
The proprietary app, on the other hand, will be near-impossible to patch for even the most trivial of changes without the original source code or build environment—and let's not forget that distributing the modified version would be illegal; at best you might get instructions for patching your own copy. And of course there won't be any growth in the user community since there is no (legal) source for new copies. Existing users may be able to struggle along on their own for a while but this is ultimately a dead end without support from the copyright holder.
IMHO this understates the difference, severely. The open source app can be maintained by the community for as long as it has a community. That includes not just dealing with dependency obsolescence but also new features, redesign, porting to new platforms… anything that would have been handled by the original team.
The proprietary app, on the other hand, will be near-impossible to patch for even the most trivial of changes without the original source code or build environment—and let's not forget that distributing the modified version would be illegal; at best you might get instructions for patching your own copy. And of course there won't be any growth in the user community since there is no (legal) source for new copies. Existing users may be able to struggle along on their own for a while but this is ultimately a dead end without support from the copyright holder.
Surely that's a good point and it would definitely help, but just because something is open source does not necessarily mean that it will stay alive in the way you describe it - especially redesign or new features. Patches is the best the user of an abandoned app could hope for.
My point was mainly in the context of Electron desktop apps, an abandoned, proprietary Electron app would probably run for at least 5 years * without touching it after it's abandoned. Further from that point patching it so it works would not be that hard. On the other hand I imagine an unmaintained C++ desktop app could decay pretty fast if it depends on some external lib so here a proprietary app could indeed be very hard or next to impossible to patch.
* I did not consider security patches though, if an Electron app processes potentially untrusted third party files and / or connects to external services, it may require security patches and that would be also hard / impossible to patch, I agree here - though updating its Electron binary could go a long way with security, which is not that hard.
Edit: Ok, I guess there may be issues with Electron too. If Electron binary is kept up to date, Electron deprecates some APIs regularly and that could break it. So it's either that or running a very old Electron instance - which may or may not be fine, depending on the app and how it's used.
My point was mainly in the context of Electron desktop apps, an abandoned, proprietary Electron app would probably run for at least 5 years * without touching it after it's abandoned. Further from that point patching it so it works would not be that hard. On the other hand I imagine an unmaintained C++ desktop app could decay pretty fast if it depends on some external lib so here a proprietary app could indeed be very hard or next to impossible to patch.
* I did not consider security patches though, if an Electron app processes potentially untrusted third party files and / or connects to external services, it may require security patches and that would be also hard / impossible to patch, I agree here - though updating its Electron binary could go a long way with security, which is not that hard.
Edit: Ok, I guess there may be issues with Electron too. If Electron binary is kept up to date, Electron deprecates some APIs regularly and that could break it. So it's either that or running a very old Electron instance - which may or may not be fine, depending on the app and how it's used.
> … just because something is open source does not necessarily mean that it will stay alive in the way you describe it - especially redesign or new features.
True, being open source doesn't guarantee that the app will be maintained. It does, however, provide the legal framework to make it possible. If the app has an active user base then it's likely that someone would step up to take over the development, and the open source nature of the project means that the new maintainers are not starting at a significant disadvantage.
> My point was mainly in the context of Electron desktop apps, an abandoned, proprietary Electron app would probably run for at least 5 years * without touching it after it's abandoned. Further from that point patching it so it works would not be that hard.
Okay, so you're assuming an app distributed mostly in source form to begin with. That's fair, but an Electron app can be minified or obfuscated (and in the case of a proprietary app, probably would be) so it wouldn't necessarily be easier to work with than a compiled binary. You also still have the copyright issues which would make it difficult to collaborate on any patches.
True, being open source doesn't guarantee that the app will be maintained. It does, however, provide the legal framework to make it possible. If the app has an active user base then it's likely that someone would step up to take over the development, and the open source nature of the project means that the new maintainers are not starting at a significant disadvantage.
> My point was mainly in the context of Electron desktop apps, an abandoned, proprietary Electron app would probably run for at least 5 years * without touching it after it's abandoned. Further from that point patching it so it works would not be that hard.
Okay, so you're assuming an app distributed mostly in source form to begin with. That's fair, but an Electron app can be minified or obfuscated (and in the case of a proprietary app, probably would be) so it wouldn't necessarily be easier to work with than a compiled binary. You also still have the copyright issues which would make it difficult to collaborate on any patches.
I'll my personal experience as someone who still prefers many proprietary softwares over open source (assuming the price is fair and the features are much much better):
- Photoshop is a market leader so definitely an exception. I personally miss apps like "Made with Mischief" which had unique features that I loved that are still not yet replicated but have completely disappeared and the only way to use them is to find shady places giving out cracked versions (even when I have a license).
- If there's enough demand for a feature, you can fork and bring it back. Waterfox is a popular example of push-back to some of Mozilla decisions (like killing XUL) and is still maintained and loved.
- I love thinkering with formats, but unless you rely on the reverse engineering community at large picking your favorite format apart, you're not gonna get far without a lot of background. I use Affinity Photo/Designer, two popular alternatives to Photoshop/Illustrator, which use their afphoto/afdesign formats and there's no published spec about them. If I ever wanted to do a tool that deals with them I'd have no starting point.
- Photoshop is a market leader so definitely an exception. I personally miss apps like "Made with Mischief" which had unique features that I loved that are still not yet replicated but have completely disappeared and the only way to use them is to find shady places giving out cracked versions (even when I have a license).
- If there's enough demand for a feature, you can fork and bring it back. Waterfox is a popular example of push-back to some of Mozilla decisions (like killing XUL) and is still maintained and loved.
- I love thinkering with formats, but unless you rely on the reverse engineering community at large picking your favorite format apart, you're not gonna get far without a lot of background. I use Affinity Photo/Designer, two popular alternatives to Photoshop/Illustrator, which use their afphoto/afdesign formats and there's no published spec about them. If I ever wanted to do a tool that deals with them I'd have no starting point.
> discontinued: Atom just got discontinued. It's open source. Photoshop on the other hand has withstood the test of time.
Photoshop has not withstood the test of time for me. I did a lot of Photoshop a few decades ago. I can't afford > $1000 per year for a hobby. My old Photoshop files are dead, for all intents and purposes.
I do occasionally use decades-old, unmaintained open-source tools to open old files.
> 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.
Yes, it does. Cloud-based, you have no choice. Installed, increasingly, you have no choice either, since activation servers get taken down.
> 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.
It's a check-and-balance. I fix issues maybe in 0.0001% of the tools I use, but when I do, it's really important. With proprietary, you can work 70 hours per week for five years, and invest your blood and soul into a project, and be left hanging at the end, because you're reliant on someone else.
With open-source, you bite the bullet, fix it yourself, and keep chugging along.
> you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
My experience is that "leading tool" is way oversold. The difference between JQuery a decade ago and React today is important, but even a huge difference like that won't make-or-break a business or a project. Technology is easy. If I needed to write my stuff in FORTRAN, I'd be less productive, but in the end, I'd learn FORTRAN and get the job done.
It's not a reason I'd pick proprietary over open-source.
What is important is all the other stuff. If you've bought something from Oracle or Google -- who are famous for this -- and they discontinue your product or ramp up licensing costings 100x once you've built your infrastructure around them, that CAN and WILL break a business (or a personal project).
Startups have a short half-life. Big businesses have a longer one ("No one got fired for buying IBM"). Open-source is eternal.
Legacy is important. If you don't believe me, have a look at all the FORTRAN and COBOL code still running on old mainframes. If you don't take long-term into account, you're unlikely to do anything lasting.
Photoshop has not withstood the test of time for me. I did a lot of Photoshop a few decades ago. I can't afford > $1000 per year for a hobby. My old Photoshop files are dead, for all intents and purposes.
I do occasionally use decades-old, unmaintained open-source tools to open old files.
> 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.
Yes, it does. Cloud-based, you have no choice. Installed, increasingly, you have no choice either, since activation servers get taken down.
> 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.
It's a check-and-balance. I fix issues maybe in 0.0001% of the tools I use, but when I do, it's really important. With proprietary, you can work 70 hours per week for five years, and invest your blood and soul into a project, and be left hanging at the end, because you're reliant on someone else.
With open-source, you bite the bullet, fix it yourself, and keep chugging along.
> you'll never have a guarantee that a tool you invest time in or money in will be the leading tool in five years.
My experience is that "leading tool" is way oversold. The difference between JQuery a decade ago and React today is important, but even a huge difference like that won't make-or-break a business or a project. Technology is easy. If I needed to write my stuff in FORTRAN, I'd be less productive, but in the end, I'd learn FORTRAN and get the job done.
It's not a reason I'd pick proprietary over open-source.
What is important is all the other stuff. If you've bought something from Oracle or Google -- who are famous for this -- and they discontinue your product or ramp up licensing costings 100x once you've built your infrastructure around them, that CAN and WILL break a business (or a personal project).
Startups have a short half-life. Big businesses have a longer one ("No one got fired for buying IBM"). Open-source is eternal.
Legacy is important. If you don't believe me, have a look at all the FORTRAN and COBOL code still running on old mainframes. If you don't take long-term into account, you're unlikely to do anything lasting.
> I can't afford > $1000 per year for a hobby.
In the UK a year's license for Photoshop, Lightroom and Bridge is approx £110.
In the UK a year's license for Photoshop, Lightroom and Bridge is approx £110.
That doesn't help him if he doesn't live in the UK though?
No but I can't believe US prices are almost ten times more expensive. If they are, he has a point
> I did a lot of Photoshop a few decades ago. I can't afford > $1000 per year for a hobby.
Adobe's Photographer Plan, which includes Photoshop and Lightroom, is $9.99 a month, $119 a year. Not sure where "over a thousand dollars per year" comes from.
Adobe's Photographer Plan, which includes Photoshop and Lightroom, is $9.99 a month, $119 a year. Not sure where "over a thousand dollars per year" comes from.
CS suite subscription. I also do illustrations, edit videos, do page layout, etc.
I used to have Photoshop, PageMaker (then Quark), etc.
Price is $55/mo, which comes out to $660 per year. Apparently, I misrecalled the price.
But I can't afford $660/year either, for a hobby.
I used to have Photoshop, PageMaker (then Quark), etc.
Price is $55/mo, which comes out to $660 per year. Apparently, I misrecalled the price.
But I can't afford $660/year either, for a hobby.
lots of modern proprietary software does require a license to to continue to use and cloud version are updated all the time without any input at all for you.
Software like Photoshop exist because of software patents and lawyers, not because they legitimately make the best product. If we stripped their parents and any ability to enforce IP we would have an OS replacement tomorrow.
To piggyback off this, another reason that I think software freedom is valuable is community support. Things like LSPs, syntax highlighters, and that sort of support doesn't have to wait on JetBrains to integrate it into their IDE. I think there is real value to the community being able to hack on a tool and not being at the whim of a single developer's priorities
Except for core functionality, everything in JetBrains' IDEs is written as plugins (grammar checking, themes, support for Go/PHP/Ruby/Python/Android/framework of the month, the list goes on). You just don't notice it because of good integration with the rest of the editor (unlike how it's done in Eclipse).
Those can be (and are) developed by anybody. For example, IDEA has had absolutely the best Rust story for many years, and the Rust plugin became official only recently. It was created and developed for years before that by a single developer not affiliated with JB (and still blew all other editors out of the water).
Those can be (and are) developed by anybody. For example, IDEA has had absolutely the best Rust story for many years, and the Rust plugin became official only recently. It was created and developed for years before that by a single developer not affiliated with JB (and still blew all other editors out of the water).
I just adapted the intellij-rust plugin from https://github.com/intellij-rust/intellij-rust to syntax highlight Rust slightly better. It works just fine, and I had to coordinate with nobody. Just edit file, build plugin, install plugin to the IDE (using the menu in the GUI interface). That's it.
Most of the stuff of Jetbrains is open source (under Apache Software License) and is available on github.
I know what you mean though: I would never again use a closed-source IDE, or a language with closed-source standard library. Microsoft Visual Studio made me learn that, decades ago.
Most of the stuff of Jetbrains is open source (under Apache Software License) and is available on github.
I know what you mean though: I would never again use a closed-source IDE, or a language with closed-source standard library. Microsoft Visual Studio made me learn that, decades ago.
You can write and publish your own plugins for JetBrains IDEs.
https://plugins.jetbrains.com/
https://plugins.jetbrains.com/
You can also sell your plugins, but it does feel less "good" to be adding value to a commercial product that you're not a part of. By that, I mean there is somewhat of a sense of community around OSS that you can't replicate within a commercial space.
I feel sentiments like these are straight paranoia. Nothing is forever. And I actually don't think I have experienced a paid piece of software suddenly changing or disappearing or causing headache. Yet, this happens all the time with free, open source software. The person developing it stops, it gets forked, now there's two versions with one the popular one but not developed and a forked one being developed but not popular, and the whole thing is difficult to contribute to because it's a big ball of mud.
I will absolutely pay for software. What's more likely to cause issues? A company getting paid to develop useful software or some free, open source software where the developers have their own little fiefdom? Issues get closed all the time or ignored and then when you push the issue you just get told "that's not the way I do it" or "we're all volunteers and not paid, contributions welcome". Well yea, I would contribute if it wasn't impenetrable and I had confidence the contribution would actually be accepted. I have successfully contributed to larger projects where these things are taken more seriously, but they are the outlier.
I will absolutely pay for software. What's more likely to cause issues? A company getting paid to develop useful software or some free, open source software where the developers have their own little fiefdom? Issues get closed all the time or ignored and then when you push the issue you just get told "that's not the way I do it" or "we're all volunteers and not paid, contributions welcome". Well yea, I would contribute if it wasn't impenetrable and I had confidence the contribution would actually be accepted. I have successfully contributed to larger projects where these things are taken more seriously, but they are the outlier.
- You can keep your editor with Jetbrains even after the license expires, you just don't get updates.
- They never force you into updates.
- Many of my LaTeX files from 20 years ago don't work anymore unless I go back and go use old versions.
- Your IDE does not modify your source code so your source code stays in an interpretable format.
I agree that you loose the ability to modify and adapt your editor (beyond plugins but that's still pretty limited compared to what you can do with emacs for example)
Using an editor doesn't force you to stay in a relation for life. if Jetbrains turns into a cash cow, I can go use any editor I want. Outside of muscle memory and preference, I have 0 dependency on them.
I agree that you loose the ability to modify and adapt your editor (beyond plugins but that's still pretty limited compared to what you can do with emacs for example)
Using an editor doesn't force you to stay in a relation for life. if Jetbrains turns into a cash cow, I can go use any editor I want. Outside of muscle memory and preference, I have 0 dependency on them.
> You don't know when it will disappear or be discontinued.
I've been using Visual Studio pretty much every working day for over twenty years. I have zero worries that is will disappear any time soon. I still think its the best IDE out there, and I've never felt that my freedom was being compromised by using it.
I've been using Visual Studio pretty much every working day for over twenty years. I have zero worries that is will disappear any time soon. I still think its the best IDE out there, and I've never felt that my freedom was being compromised by using it.
You are so incredibly wrong. Visual Studio was a horrible IDE for most of the past 20 years, relative to competitors. Quite literally the only reason it picked up marketshare was that it supported new Windows features before Borland could. Borland was miles ahead in every other respect.
Microsoft continued to suck, in virtually all respects, relative to competition, until around 2015.
I don't quite understand how Microsoft suddenly became competent, and released an awesome IDE, but that's a very new phenomenon.
Microsoft continued to suck, in virtually all respects, relative to competition, until around 2015.
I don't quite understand how Microsoft suddenly became competent, and released an awesome IDE, but that's a very new phenomenon.
With proprietary software:
- You might be forced into an "upgrade" which breaks something you rely on
GNOME devs are laughing at this very hard right now while they look at your maximize icon. As of today, half baked decisions are still being made and forced to users all around.
Like Gnome Terminal, where if you Select All, then Copy, it only copies the currently visible text, not the "All" you just selected. A conscious decision that was first made to work around some memory issue, and was later left as permanent behavior with no resort for users to revert back and absolutely no way to select and copy all text of a terminal. And it shipped for everybody to enjoy on the latest Ubuntu LTS. Nice.
EDIT to mention that indeed it's nice that Ubuntu themselves would be in a position where the change could be reverted for their users, if they wanted. So that's indeed a very positive property of Open Source. Albeit assuming everybody has the means, the time, or even the ability to make such changes is kind of naive. But the possibility, yeah, it is there after all, and that's a good thing.
- You might be forced into an "upgrade" which breaks something you rely on
GNOME devs are laughing at this very hard right now while they look at your maximize icon. As of today, half baked decisions are still being made and forced to users all around.
Like Gnome Terminal, where if you Select All, then Copy, it only copies the currently visible text, not the "All" you just selected. A conscious decision that was first made to work around some memory issue, and was later left as permanent behavior with no resort for users to revert back and absolutely no way to select and copy all text of a terminal. And it shipped for everybody to enjoy on the latest Ubuntu LTS. Nice.
EDIT to mention that indeed it's nice that Ubuntu themselves would be in a position where the change could be reverted for their users, if they wanted. So that's indeed a very positive property of Open Source. Albeit assuming everybody has the means, the time, or even the ability to make such changes is kind of naive. But the possibility, yeah, it is there after all, and that's a good thing.
Devs don't pay for tooling because it might be discontinued or have a paid upgrade? That seems short-sighted and perhaps an argument in search of a proponent.
The parent post argues that if you invest in learning or tweaking open source tools, they're useful to you over a longer period of time than the commercial counterparts in general. I don't read it as absolute. Just an explanation of their preference.
Along with your other points, you're not making any sense.
> - That's not to mention issues like being able to fix bugs yourself, extend it, or understand it. I don't do this often directly
That's just saying it's better for paid products because there's always someone paid to fix stuff instead of relying on volunteers.
I care to get the work done in the easiest way possible. And I hardly believe JetBrains will go away anytime soon, besides, using less productive tools until you see the paid competitors leave is really a dumb idea. If JetBrains were to disappear tomorrow and somehow they disabled my perpetual license along with them, I'll have to switch to Vscode but why let go of the benefit with your hypothetical concerns that may not materialize for years to come?
Sounds like you're just trying to create excuses to stay on your free apps.
> - That's not to mention issues like being able to fix bugs yourself, extend it, or understand it. I don't do this often directly
That's just saying it's better for paid products because there's always someone paid to fix stuff instead of relying on volunteers.
I care to get the work done in the easiest way possible. And I hardly believe JetBrains will go away anytime soon, besides, using less productive tools until you see the paid competitors leave is really a dumb idea. If JetBrains were to disappear tomorrow and somehow they disabled my perpetual license along with them, I'll have to switch to Vscode but why let go of the benefit with your hypothetical concerns that may not materialize for years to come?
Sounds like you're just trying to create excuses to stay on your free apps.
Sorry, but developers don't care about freedom, they just want things that are free == gratis == zero cost.
that's not true. Sure the majority may not care but a sizeable and talented core do or we would have nothing but proprietary software to use right now.
rnd420_69(1)
Nothing to do with freedom. People are naturally cheap.
Which is why free tiers are so popular.
Which is why free tiers are so popular.
> Nothing to do with freedom. People are naturally cheap.
I don't think this is true. Look at bars. I can go to a liquor store and buy alcohol at a fraction of what it costs in a bar and invite my friends over to drink together. Yet, bars which charge a massive markup on the same exact alcohol, do not seem to be in danger of going out of business.
Or look at coffee. You can buy a bag of Starbucks coffee in the grocery store for $10 and it will make many pots of coffee, providing a single individual a cup of coffee a day for 2 weeks or more. Yet, on any given morning you can spot long lines of people eagerly waiting to pay 3 or 4 dollars for a single cup of the exact same coffee they could have made at home for one tenth the cost, that probably would have required less time and effort than going to Starbucks.
I don't think this is true. Look at bars. I can go to a liquor store and buy alcohol at a fraction of what it costs in a bar and invite my friends over to drink together. Yet, bars which charge a massive markup on the same exact alcohol, do not seem to be in danger of going out of business.
Or look at coffee. You can buy a bag of Starbucks coffee in the grocery store for $10 and it will make many pots of coffee, providing a single individual a cup of coffee a day for 2 weeks or more. Yet, on any given morning you can spot long lines of people eagerly waiting to pay 3 or 4 dollars for a single cup of the exact same coffee they could have made at home for one tenth the cost, that probably would have required less time and effort than going to Starbucks.
That's paying for convenience which is a different behavior.
When exactly would paying for an IDE extension NOT be paying for convenience?
What is the convenience?
- you don’t have to learn how to make all the variations of drinks each of your friends like
- you don’t have to stock ingredients for food/drinks you may not like or prepare often
- you can’t make a din without annoying the neighbours
- you don’t have to rent a space just to play loud music or dance
- you don’t have to make a music selection
- you don’t have to invite large numbers of people who don’t know each other to help make new connections
- you don’t have to clean up every time anyone pukes
- you don’t have to stock ingredients for food/drinks you may not like or prepare often
- you can’t make a din without annoying the neighbours
- you don’t have to rent a space just to play loud music or dance
- you don’t have to make a music selection
- you don’t have to invite large numbers of people who don’t know each other to help make new connections
- you don’t have to clean up every time anyone pukes
Cheapness is freedom, from expending resources.
I'm not rich and a lot of paid tiers are targeting 5+ seat enterprise companies instead of individuals.
So do you only work for companies who have 100% open source and whose business model or product is a public benefit? Eg, "I value my freedom" is a perfectly acceptable position, until Mark Zuckerberg starts signing your checks, you know?
Facebook/Meta are huge contributors to open source, so I'm not sure what your comment is supposed to mean.
Their products are proprietary. Honestly open sourcing their stuff just nets free labor.
Are you trying to claim that something like React/React Native/Jest weren't mostly done by Meta, but by the open source community, and Meta was just riding the coattails of their free work? You count VSCode to be in the same category as well (swap Meta for Microsoft instead)?
That's quite a claim, and I dont believe it is substantiated.
That's quite a claim, and I dont believe it is substantiated.
No, I'm saying any benefit by open sourcing it vs. just keeping it in house (the difference) would be free labor. Not the entire project of course!
> but the Jetbrains IDEs are simply better and more mature in every single way
That's just not true.
I have access to the full Jetbrains suite for free, yet I still opt to use Neovim or VS Code/Codium for most languages.
Jetbrains IDEs are great in many ways, but are objectively worse on several metrics:
* slow startup times
* slow initial operations until the JIT is warmed up
* even once warm, you always eventually do something that lags or blocks the UI, maybe barely enough to consciously notice, maybe for several seconds; and it really affects user experience if you care about latency - it drives me crazy each time
* plugins: VS Code has a wide range of great plugins, many more than the Jetbrains ecosystem and especially when it comes to more niche languages or functionality, Vim/emacs but also VS Code are much more extensible in general
* keyboard warriors: the Vim plugin is fine, and you can configure the Jetbrains IDEs to do almost anything with the keyboard, but you need way more arcane knowledge in the form of memorized context-specific bindings, and you always eventually forget something and need to switch back to the mouse. Vim and emacs are just much better there. VS Code is actually also better, because the interactions are significantly more customizable.
* Wayland / tiling WM / input lag: Jetbrains products really suck on tiling window managers like i3 / sway because they use native windows for dialogs. They also don't support Wayland natively, so they run through X server emulation which hurts input lag and brings plenty of bugs like weird dialog behaviour. In general the input lag is quite bad on Linux, it seems to be much better optimized on Mac OS
There are plenty of valid reasons why you wouldn't want to use their IDEs, even if they provide more integration and superior refactoring.
That's just not true.
I have access to the full Jetbrains suite for free, yet I still opt to use Neovim or VS Code/Codium for most languages.
Jetbrains IDEs are great in many ways, but are objectively worse on several metrics:
* slow startup times
* slow initial operations until the JIT is warmed up
* even once warm, you always eventually do something that lags or blocks the UI, maybe barely enough to consciously notice, maybe for several seconds; and it really affects user experience if you care about latency - it drives me crazy each time
* plugins: VS Code has a wide range of great plugins, many more than the Jetbrains ecosystem and especially when it comes to more niche languages or functionality, Vim/emacs but also VS Code are much more extensible in general
* keyboard warriors: the Vim plugin is fine, and you can configure the Jetbrains IDEs to do almost anything with the keyboard, but you need way more arcane knowledge in the form of memorized context-specific bindings, and you always eventually forget something and need to switch back to the mouse. Vim and emacs are just much better there. VS Code is actually also better, because the interactions are significantly more customizable.
* Wayland / tiling WM / input lag: Jetbrains products really suck on tiling window managers like i3 / sway because they use native windows for dialogs. They also don't support Wayland natively, so they run through X server emulation which hurts input lag and brings plenty of bugs like weird dialog behaviour. In general the input lag is quite bad on Linux, it seems to be much better optimized on Mac OS
There are plenty of valid reasons why you wouldn't want to use their IDEs, even if they provide more integration and superior refactoring.
I haven’t checked in a couple years, but this mirrors my experience very closely.
I pay for good editors just to support the creators. I want to pay for the one I use daily. The reality is that vscode is the most extensible, performant on average (not in all ways), and useful IDE I have.
I pay for good editors just to support the creators. I want to pay for the one I use daily. The reality is that vscode is the most extensible, performant on average (not in all ways), and useful IDE I have.
Most of your pain points are mostly superficial. Yes, it's slow to start, but I close my projects rarely enough for that not to matter.
Yes, there are possibly more plugins for VS Code, but they are largely shit, aren't they?
Yes, LS has made it possible to create rudimentary editing capabilities for languages that always lacked them, and that is unironically a good thing. But for bigger/established languages VS Code provides maybe 10% of functionality that Jetbrains IDEs provide.
Yes, there are possibly more plugins for VS Code, but they are largely shit, aren't they?
Yes, LS has made it possible to create rudimentary editing capabilities for languages that always lacked them, and that is unironically a good thing. But for bigger/established languages VS Code provides maybe 10% of functionality that Jetbrains IDEs provide.
That IntelliJ exists at all is a condemnation of how bloated and generally ridiculous Java has become. I die a little inside every time I use it, but the alternatives for developing in a large Java codebase are all worse.
I'm using PyCharm in i3 daily, and it works great.
There was a bug around input focus of certain Windows once, it had an immediate work around, and Jetbrains fixed the bug in a reasonable time frame for the probably pretty small percentage of users on i3.
Jetbrains IDEs are not the greatest example for why free software is better; they actually a rare example of proprietary software working really well.
There was a bug around input focus of certain Windows once, it had an immediate work around, and Jetbrains fixed the bug in a reasonable time frame for the probably pretty small percentage of users on i3.
Jetbrains IDEs are not the greatest example for why free software is better; they actually a rare example of proprietary software working really well.
I agree with the rest of your points, but keyboard navigation in VSC just blows (or I'm doing something very wrong). It's painfully obvious main VSCode developers must be heavy mouse users because you just can't do some things there without a mouse, or they're really awkward (for example, de-focusing the sidebar requires pressing some weird key combo (I think it's Ctrl+Shift+E or something like that?), while a simple Escape works in IDEA for all similar situations — de-focus the sidebar, de-focus a search result/debugger/whatever pane, close the search dialog, basically anything that means "go back to editing the code").
I couldn't find a key combo (or any way to configure it) to navigate between classes and functions in the same file. I find this to be very useful, I must be pressing it hundreds of times a day. VSC expects you to focus on the breadcrumb pane, arrow up or down to the name of the member you'd like to jump to, and press Enter, while in IDEA you just press Alt+ArrowUp (or down) and quickly jump between functions in the same file.
Same with search results. Do a search in IDEA, press Ctrl+Enter, it moves the result list to the search pane. Pressing Ctrl+Alt+Arrow(Up|Down) lets you quickly jump between them. That's another thing I just can't live without. I couldn't find anything like that in VSCode, search is so awkward to use I just drop out to the shell and use ripgrep directly.
Close to 100% of IDEA/Rider's functionality can be controlled through the keyboard, and I think the developers themselves are using it heavily, because it's configured out of the box, hotkeys are discoverable once you understand the logic behind them, and they make sense (unlike in VSCode where hotkeys for many important functions are either not assigned at all, or are awkward out of the box. For example, who in the hell decided to bind "jump to definition" to F12? I'm getting flashbacks to how we played Mortal Kombat at the beginning of the century where you were expected to quickly press difficult key sequences to perform spectacular fighting combos.)
I couldn't find a key combo (or any way to configure it) to navigate between classes and functions in the same file. I find this to be very useful, I must be pressing it hundreds of times a day. VSC expects you to focus on the breadcrumb pane, arrow up or down to the name of the member you'd like to jump to, and press Enter, while in IDEA you just press Alt+ArrowUp (or down) and quickly jump between functions in the same file.
Same with search results. Do a search in IDEA, press Ctrl+Enter, it moves the result list to the search pane. Pressing Ctrl+Alt+Arrow(Up|Down) lets you quickly jump between them. That's another thing I just can't live without. I couldn't find anything like that in VSCode, search is so awkward to use I just drop out to the shell and use ripgrep directly.
Close to 100% of IDEA/Rider's functionality can be controlled through the keyboard, and I think the developers themselves are using it heavily, because it's configured out of the box, hotkeys are discoverable once you understand the logic behind them, and they make sense (unlike in VSCode where hotkeys for many important functions are either not assigned at all, or are awkward out of the box. For example, who in the hell decided to bind "jump to definition" to F12? I'm getting flashbacks to how we played Mortal Kombat at the beginning of the century where you were expected to quickly press difficult key sequences to perform spectacular fighting combos.)
> I couldn't find a key combo (or any way to configure it) to navigate between classes and functions in the same file.
That's an interesting use case, it totally makes sense, it's something I don't know I could have, even though I rarely use mouse. I'm just used to Ctrl+Shift+O and search for member names.
I guess that's the real value of a well-designed IDE. It has everything you may find useful and made it discoverable. Once you know such thing exists, you can... https://marketplace.visualstudio.com/items?itemName=mishkinf...
> who in the hell decided to bind "jump to definition" to F12
Well, it's "Visual Studio" Code, and Visual Studio had this keybinding for at least 20 years. I understand that it does not work for you, but there is a reason.
I grew up using zero Macs, so "go to definition" in my brain always map to "F12 as a single key, or gd in normal mode in a modal editor". Oh, and F12 is easily reachable on an US ANSI 104 keyboard.
That's an interesting use case, it totally makes sense, it's something I don't know I could have, even though I rarely use mouse. I'm just used to Ctrl+Shift+O and search for member names.
I guess that's the real value of a well-designed IDE. It has everything you may find useful and made it discoverable. Once you know such thing exists, you can... https://marketplace.visualstudio.com/items?itemName=mishkinf...
> who in the hell decided to bind "jump to definition" to F12
Well, it's "Visual Studio" Code, and Visual Studio had this keybinding for at least 20 years. I understand that it does not work for you, but there is a reason.
I grew up using zero Macs, so "go to definition" in my brain always map to "F12 as a single key, or gd in normal mode in a modal editor". Oh, and F12 is easily reachable on an US ANSI 104 keyboard.
Thanks for the pointer, this seems to work. The plugin seems to have appeared after I last checked for something like that.
Now only to make search at least quarter as good as it is in IDEA (it seems to be very underappreciated for such an important piece of functionality): jumping between results, grouping results by the class/function they appear in, filtering by access type (declaration/definition/read value/write value), etc etc.
Jump up & down has a different use case compared to symbol search (which I too use heavily). If the program is well-structured (i.e. functions are of reasonable size and things that depend on each other and call each other are located nearby), it eases the pain of trying to understand how it all ties together, especially for those with bad short-term memory like myself.
Now only to make search at least quarter as good as it is in IDEA (it seems to be very underappreciated for such an important piece of functionality): jumping between results, grouping results by the class/function they appear in, filtering by access type (declaration/definition/read value/write value), etc etc.
Jump up & down has a different use case compared to symbol search (which I too use heavily). If the program is well-structured (i.e. functions are of reasonable size and things that depend on each other and call each other are located nearby), it eases the pain of trying to understand how it all ties together, especially for those with bad short-term memory like myself.
I have jetbrains license but i still use vim almost 80% of the time for the reasons you mentioned.
kingboss(1)
> I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way.
Yeah, no. Don't get me wrong, Jetbrains IDEs are great. But they're not as easy to extend, its proprietary nature makes it hard to debug when writing extensions.
I use neovim primarily, but I've got licenses for a bunch of other editors (Nova, Sublime, used to have IntelliJ). I do sincerely try them, but I keep going back to open source, extensible editors like vim, emacs, vscode... because I invariably need to tweak something in the editor, and doing so in the proprietary editors can be so damn painful.
Now, you do make a solid point though. I guess I probably should donate to neovim. Guess I'll go do that!
Yeah, no. Don't get me wrong, Jetbrains IDEs are great. But they're not as easy to extend, its proprietary nature makes it hard to debug when writing extensions.
I use neovim primarily, but I've got licenses for a bunch of other editors (Nova, Sublime, used to have IntelliJ). I do sincerely try them, but I keep going back to open source, extensible editors like vim, emacs, vscode... because I invariably need to tweak something in the editor, and doing so in the proprietary editors can be so damn painful.
Now, you do make a solid point though. I guess I probably should donate to neovim. Guess I'll go do that!
Yup, it’s definitely not a money thing. There’s plenty of tooling I do pay for, but I like hacking on my editor.
Sure, you need to go deep sometimes to tune things how you want, but hey, that’s what we do, right?
The important point is that people have different priorities and will make different trade offs. For me I like lean, fast and hackable. For others it’s that they don’t want to have to understand or configure it. That’s totally fine.
Sure, you need to go deep sometimes to tune things how you want, but hey, that’s what we do, right?
The important point is that people have different priorities and will make different trade offs. For me I like lean, fast and hackable. For others it’s that they don’t want to have to understand or configure it. That’s totally fine.
You're right that it's a totally different mindset. I was going to post a comment along the lines of "anytime I need to hack my editor, it's a waste of my time". That's where IntelliJ shines. It's so mature and functional out of the box, that I don't need to hack it. I came from Emacs where, once the initial fun of hacking it wore off, it was just a drag.
I also like that Microsoft has made it incredibly easy to create an extension for VS Code. Most of the functionality usually doesn't even require code, just modifying the package.json file to add UI elements and such.
> Yeah, no. Don't get me wrong, Jetbrains IDEs are great. But they're not as easy to extend, its proprietary nature makes it hard to debug when writing extensions.
IntelliJ IDEA Community Edition is open source under Apache License 2.0:
https://github.com/JetBrains/intellij-community
IntelliJ IDEA Community Edition is open source under Apache License 2.0:
https://github.com/JetBrains/intellij-community
This repo contains all the free versions including Pycharm
> What I find truly bizarre is how many software engineers, who are aware of how much they earn and how long it really takes to make software, are so resistant to paying anything for tools that make their job easier and faster. It blows my mind.
We're not resistant to paying, we're resistant to rent-seeking. I would, and have, happily buy a piece of software I use regularly.
What I will not do is a pay a monthly fee in perpetuity for a piece of software that I cannot truly own, where features I need can be removed on a whim and where I am prohibited from adding features I want. I also find the massive amount of tracking and general disregard for privacy appalling, but that's a missive for another day.
The subscription model that's become predominant is a nightmare and is increasingly user-hostile. Why is it so surprising that a lot of folks don't like it?
So in summary, I will gladly pay for software when:
1. I can pay up front an actually own it
2. I can see the source code and modify it
3. It does not track or otherwise monitor me
None of these things are a big ask.
We're not resistant to paying, we're resistant to rent-seeking. I would, and have, happily buy a piece of software I use regularly.
What I will not do is a pay a monthly fee in perpetuity for a piece of software that I cannot truly own, where features I need can be removed on a whim and where I am prohibited from adding features I want. I also find the massive amount of tracking and general disregard for privacy appalling, but that's a missive for another day.
The subscription model that's become predominant is a nightmare and is increasingly user-hostile. Why is it so surprising that a lot of folks don't like it?
So in summary, I will gladly pay for software when:
1. I can pay up front an actually own it
2. I can see the source code and modify it
3. It does not track or otherwise monitor me
None of these things are a big ask.
JetBrains products have a perpetual fallback license so you absolutely can pay up front and then never pay again if you are ok being on an older version of the software.
Maybe you are the exception but I find that 99.99% of the people who use the "it's open source so I can modify it" argument never so much as look at the code let alone consider making modifications.
JetBrains products have an open-core (IntelliJ [0]) that can look at and contribute to if you so desire.
Lastly you say "None of these things are a big ask.", you just want the world on a silver platter for no cost, sorry but that is a big ask, especially if you care at all about the quality of your tools. If you're happy building an IDE from the group up using something like vscode and dealing with 100's of plugins that do the same thing slightly differently then be my guest but most of your arguments fall flat IMHO. Providing an excellent product with constant updates is not "rent-seeking".
[0] https://github.com/JetBrains/intellij-community
Maybe you are the exception but I find that 99.99% of the people who use the "it's open source so I can modify it" argument never so much as look at the code let alone consider making modifications.
JetBrains products have an open-core (IntelliJ [0]) that can look at and contribute to if you so desire.
Lastly you say "None of these things are a big ask.", you just want the world on a silver platter for no cost, sorry but that is a big ask, especially if you care at all about the quality of your tools. If you're happy building an IDE from the group up using something like vscode and dealing with 100's of plugins that do the same thing slightly differently then be my guest but most of your arguments fall flat IMHO. Providing an excellent product with constant updates is not "rent-seeking".
[0] https://github.com/JetBrains/intellij-community
> Maybe you are the exception but I find that 99.99% of the people who use the "it's open source so I can modify it" argument never so much as look at the code let alone consider making modifications.
I like to live in a country with free speech even if I am not a journalist. For the same reason, even if I personally am not modifying much, I want the software I use to be libre. Nothing about price.
https://www.gnu.org/philosophy/selling.en.html
I like to live in a country with free speech even if I am not a journalist. For the same reason, even if I personally am not modifying much, I want the software I use to be libre. Nothing about price.
https://www.gnu.org/philosophy/selling.en.html
> Maybe you are the exception but I find that 99.99% of the people who use the "it's open source so I can modify it" argument never so much as look at the code let alone consider making modifications.
It's about having the option. It shouldn't be the case that you have to modify your editor's source code, but if it's open source, at least you can do that. With a proprietary editor, you're screwed.
It's about having the option. It shouldn't be the case that you have to modify your editor's source code, but if it's open source, at least you can do that. With a proprietary editor, you're screwed.
How are you screwed?
If you don’t like something, switch editors. I don’t understand why some people self-flagellate and don’t just pick the right tool for the job. I’m very pro-open-source but that doesn’t mean proprietary software is all evil, you’ll drive yourself crazy if you take that to its logical end.
If you don’t like something, switch editors. I don’t understand why some people self-flagellate and don’t just pick the right tool for the job. I’m very pro-open-source but that doesn’t mean proprietary software is all evil, you’ll drive yourself crazy if you take that to its logical end.
> If you don’t like something, switch editors. I don’t understand why some people self-flagellate and don’t just pick the right tool for the job.
As an emacs user: One does not simply switch editors.
If you can just switch from emacs to vscode, you likely were using it at a very surface level.
Put another way one could switch from Java (jetbrains) to Scala(emacs), but still be writing Java code.
I think that there are users that treat IDEs and editors as a lowest common denominator where switching would be easy and others who build workflows on editor-specific features.
If you are the former, switching isn't a big deal.
As an emacs user: One does not simply switch editors.
If you can just switch from emacs to vscode, you likely were using it at a very surface level.
Put another way one could switch from Java (jetbrains) to Scala(emacs), but still be writing Java code.
I think that there are users that treat IDEs and editors as a lowest common denominator where switching would be easy and others who build workflows on editor-specific features.
If you are the former, switching isn't a big deal.
> Lastly you say "None of these things are a big ask.", you just want the world on a silver platter for no cost, sorry but that is a big ask,
Silver platter? Lol. Each of these things would require *less* effort on the part of software companies, not more.
Upfront payment? It's easier to charge once than to set up recurring bill pay.
Open source? You already have the code, just let me see it.
Tracking? Just don't track me. Actually requires the company and it's devs to write less code not more. Companies managed to successfully sell software for many years without tracking and spying on their users
> Providing an excellent product with constant updates is not "rent-seeking"
It is when the updates are things I and others do not want, or need, and did not ask for. I have an old computer running 15 year-old version of MS Office. Not once have I have ever had need for one of the newer features for Office that MS has rolled out in the last decade and a half. That might not be true for everyone, but it's true for me and many others.
Silver platter? Lol. Each of these things would require *less* effort on the part of software companies, not more.
Upfront payment? It's easier to charge once than to set up recurring bill pay.
Open source? You already have the code, just let me see it.
Tracking? Just don't track me. Actually requires the company and it's devs to write less code not more. Companies managed to successfully sell software for many years without tracking and spying on their users
> Providing an excellent product with constant updates is not "rent-seeking"
It is when the updates are things I and others do not want, or need, and did not ask for. I have an old computer running 15 year-old version of MS Office. Not once have I have ever had need for one of the newer features for Office that MS has rolled out in the last decade and a half. That might not be true for everyone, but it's true for me and many others.
Do you work in tech? Like writing code? Because I honestly can't believe that someone who works in this industry could say "Each of these things would require less effort on the part of software companies, not more." with a straight face.
> Upfront payment? It's easier to charge once than to set up recurring bill pay.
Monthly bill payments on a regular schedule are not hard, huge spikes are more difficult to deal with. Also then you have feast/famine cycles at your company and hold back completed features for a year or more to sell n+1 version. I'd rather show, in real-time (monthly or annually), what I think of the software (as in continuing to pay for it if I like it) as well as get new features as soon as they are ready instead of waiting for an arbitrary point in the future.
> Open source? You already have the code, just let me see it.
Again, do you work in tech? This is nowhere near as easy as your make it out to be.
> Tracking? Just don't track me. Actually requires the company and it's devs to write less code not more. Companies managed to successfully sell software for many years without tracking and spying on their users
This can encompass a wide range of things and I don't personally believe it's all bad, the good companies allow you to opt out [0]. None of things IDEA can collect bother me and you can disable it easily. There are good reasons for wanting this data along with things like crash reports. It's to improve the product, see what features people are really using, where you should direct your efforts, what types of project structures to optimize for. Does adding the tracking take more work? Yes but we (software developers) wouldn't do it if we didn't get value out of the results.
As far as rent-seeking, I guess it's a matter of opinion. You can make the argument that you'd rather things just never change and limit yourself to dated tools that will eventually not be supported or have features you will need in the future. Or you can continue to learn and grow with the current landscape of tools letting you take advantage of new features that might end up being game-changing.
[0] https://www.jetbrains.com/help/idea/settings-usage-statistic...
> Upfront payment? It's easier to charge once than to set up recurring bill pay.
Monthly bill payments on a regular schedule are not hard, huge spikes are more difficult to deal with. Also then you have feast/famine cycles at your company and hold back completed features for a year or more to sell n+1 version. I'd rather show, in real-time (monthly or annually), what I think of the software (as in continuing to pay for it if I like it) as well as get new features as soon as they are ready instead of waiting for an arbitrary point in the future.
> Open source? You already have the code, just let me see it.
Again, do you work in tech? This is nowhere near as easy as your make it out to be.
> Tracking? Just don't track me. Actually requires the company and it's devs to write less code not more. Companies managed to successfully sell software for many years without tracking and spying on their users
This can encompass a wide range of things and I don't personally believe it's all bad, the good companies allow you to opt out [0]. None of things IDEA can collect bother me and you can disable it easily. There are good reasons for wanting this data along with things like crash reports. It's to improve the product, see what features people are really using, where you should direct your efforts, what types of project structures to optimize for. Does adding the tracking take more work? Yes but we (software developers) wouldn't do it if we didn't get value out of the results.
As far as rent-seeking, I guess it's a matter of opinion. You can make the argument that you'd rather things just never change and limit yourself to dated tools that will eventually not be supported or have features you will need in the future. Or you can continue to learn and grow with the current landscape of tools letting you take advantage of new features that might end up being game-changing.
[0] https://www.jetbrains.com/help/idea/settings-usage-statistic...
> Do you work in tech? Like writing code?
Yes and yes.
Perhaps with the exception of showing the source code, these things we're discussing are things that used to be quite common place, i.e. you could buy and own a piece of software with one upfront payment and it didn't track you.
I have very hard time believing that things that were the norm a short time ago are suddenly now impossible or prohibitively difficult.
I can understand a company pursuing things like a subscription model and expansive tracking. It's potentially more profitable, just like making it very hard replace in iPhone batter is more profitable. However, it doesn't make it right and is one of reasons a lot of developers don't like to pay for modern software. Nobody likes being fleeced and developers are in the best position to call bullshit on software.
In terms of getting new features. I will (and have) pay for a new version of a piece of software a useful feature appears. Most new features in subscription based software are just fluff designed to justify the ongoing monthly charge.
Yes and yes.
Perhaps with the exception of showing the source code, these things we're discussing are things that used to be quite common place, i.e. you could buy and own a piece of software with one upfront payment and it didn't track you.
I have very hard time believing that things that were the norm a short time ago are suddenly now impossible or prohibitively difficult.
I can understand a company pursuing things like a subscription model and expansive tracking. It's potentially more profitable, just like making it very hard replace in iPhone batter is more profitable. However, it doesn't make it right and is one of reasons a lot of developers don't like to pay for modern software. Nobody likes being fleeced and developers are in the best position to call bullshit on software.
In terms of getting new features. I will (and have) pay for a new version of a piece of software a useful feature appears. Most new features in subscription based software are just fluff designed to justify the ongoing monthly charge.
Are you ignoring the 'perpetual fallback license'? I would expect you'd welcome it if it is such a strong point for you.
You can pay once for JetBrains IDE and never ever update (or even access older version) and keep using it after that.
> Are you ignoring the 'perpetual fallback license'?
I'm not ignoring it, I'm just not a JetBrains user for reasons outside of cost. I happen to like emacs and donate to different parts of the emacs ecosystem.
Most of my development is scripting and writing a lot of glue code which doesn't benefit tremendously from an IDE. If I found myself working on large enterprise apps or doing a lot of java programming, I'd give JetBrains a look.
I'm not ignoring it, I'm just not a JetBrains user for reasons outside of cost. I happen to like emacs and donate to different parts of the emacs ecosystem.
Most of my development is scripting and writing a lot of glue code which doesn't benefit tremendously from an IDE. If I found myself working on large enterprise apps or doing a lot of java programming, I'd give JetBrains a look.
I'm a fan of Jetbrains and am now on their discounted subscription.
They are quite involved in the development of languages too. My suspicion is they have an interest in creating new language features, that users will need updated IDEs for!
They are quite involved in the development of languages too. My suspicion is they have an interest in creating new language features, that users will need updated IDEs for!
> My suspicion is they have an interest in creating new language features, that users will need updated IDEs for.
Don’t throw me in the briar patch?
If they are pushing languages forward so that developers can do more or things more efficiently then sign me up haha.
Don’t throw me in the briar patch?
If they are pushing languages forward so that developers can do more or things more efficiently then sign me up haha.
> 1. I can pay up front an actually own it
> None of these things are a big ask.
So let me get this straight. You expect (a) a software developer to create a piece of software (b) support in perpetuity (i.e. provide bug fixes) and you want to (c) only pay them once for that. Think about this for a second, especially part b, and explain to me how that should work.
Now you might say "no but what I meant is that every time a new release comes out I pay"...so then I, the software developer, will just do a new release once a year and charge you each year. Does it magically then not become "rent seeking" any more?
The other two points are perfectly reasonable.
> None of these things are a big ask.
So let me get this straight. You expect (a) a software developer to create a piece of software (b) support in perpetuity (i.e. provide bug fixes) and you want to (c) only pay them once for that. Think about this for a second, especially part b, and explain to me how that should work.
Now you might say "no but what I meant is that every time a new release comes out I pay"...so then I, the software developer, will just do a new release once a year and charge you each year. Does it magically then not become "rent seeking" any more?
The other two points are perfectly reasonable.
> Does it magically then not become "rent seeking" any more?
The difference is that i can just stop buying the new stuff once the software does everything i need though. That way i might miss out on shiny new features, but as long as the thing i bought the software for gets done I really don't have a need to purchase new versions.
The difference is that i can just stop buying the new stuff once the software does everything i need though. That way i might miss out on shiny new features, but as long as the thing i bought the software for gets done I really don't have a need to purchase new versions.
How long do you expect the version you own to be supported though? Security updates? Bug fixes? Feature requests?
I wouldn't expect feature updates at all. In my mind it works like this:
New features are adding value. This is something that the developers should be paid for! Releasing a new version for features is justified.
Security updates/bug fixes on the other hand are "fixing" things with their product. In my opinion those should be provided because developers should strive to develop good products.
But to give you a somewhat more clear answer: I don't expect new features. I expect Security and bug updates until the next version+a bit of time.
If there is a version released every year i would expect Security/bug fixes for at least one year. Two years would be the developers be great, three years would have me surprised. Anything beyond that would be far more than I ever expected.
New features are adding value. This is something that the developers should be paid for! Releasing a new version for features is justified.
Security updates/bug fixes on the other hand are "fixing" things with their product. In my opinion those should be provided because developers should strive to develop good products.
But to give you a somewhat more clear answer: I don't expect new features. I expect Security and bug updates until the next version+a bit of time.
If there is a version released every year i would expect Security/bug fixes for at least one year. Two years would be the developers be great, three years would have me surprised. Anything beyond that would be far more than I ever expected.
> In my opinion those should be provided because developers should strive to develop good products.
Developers also have to put food on the table. I think you've now answered your "is this hard to do?"...
Developers also have to put food on the table. I think you've now answered your "is this hard to do?"...
> I think you've now answered your "is this hard to do?"...
Did i buy the product "as is"? If it is an open source product then i agree with you, the product is provided as is. However, in my mind this is not the case with a commerical products.
When I buy something, whether it is software, a car or a a washing machine i have a contract that outlines what i am buying. If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me. In many countries this might even be legally required (Look for Gewährleistung/Produkthaftung in German speaking countries).
I am not asking for features. I am not asking you to make the product better than what I bought. I discovered a defect that was caused by the manufacturer, not obvious at the time of purchase and as such the product does not match what i ordered from the manufacturer. I am asking you to provide to me exactly on what we agreed upon in our contract. If a developer cannot handle that and wants to distribute their software "as is" that's fine, but that will result in my willingness to pay being lower.
If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract.
Did i buy the product "as is"? If it is an open source product then i agree with you, the product is provided as is. However, in my mind this is not the case with a commerical products.
When I buy something, whether it is software, a car or a a washing machine i have a contract that outlines what i am buying. If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me. In many countries this might even be legally required (Look for Gewährleistung/Produkthaftung in German speaking countries).
I am not asking for features. I am not asking you to make the product better than what I bought. I discovered a defect that was caused by the manufacturer, not obvious at the time of purchase and as such the product does not match what i ordered from the manufacturer. I am asking you to provide to me exactly on what we agreed upon in our contract. If a developer cannot handle that and wants to distribute their software "as is" that's fine, but that will result in my willingness to pay being lower.
If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract.
> If the product contains bugs/manufacturing defects/etc. then i expect the manufacturer to either fix those or refund me.
This analogy doesn't work with software. If you put your fridge in your house and your power goes out, you can very clearly see that your fridge is inoperable because of your power, not the fridge. Now let's try this with software:
- The software you buy supports Linux v16 but not v18. You upgrade to v18 not knowing and not your software is broken. But the software was sold to you to support v16 and not v18.
- The software you buy supports API connections to Twilio. In the docs it says "easy to use extensible API for all SMS providers". Twilio discontinues its v1 API endpoint but your software only supports v1 and not v2. You decide to migrate to Plivo and everything works except for one API call that is used once every 3 months.
And on and on and on...see the point?
> I am asking you to provide to me exactly on what we agreed upon in our contract.
Great, now the developer not only has to be a "good developer" but also an expert in contract writing (or has a lawyer that is). Or worse, the lawyer and developer must be completely and harmoniously in sync about product functionality and the contractually nature that you, the client, originally decided to sign the contract with. Note - In case you are unaware, software contracts are notoriously difficult to do well (see Google/Oracle debacle).
> If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract.
I think you're going to find the more and more you explain your position the more and more you'll see that "why is this so hard" is truly...hard.
This analogy doesn't work with software. If you put your fridge in your house and your power goes out, you can very clearly see that your fridge is inoperable because of your power, not the fridge. Now let's try this with software:
- The software you buy supports Linux v16 but not v18. You upgrade to v18 not knowing and not your software is broken. But the software was sold to you to support v16 and not v18.
- The software you buy supports API connections to Twilio. In the docs it says "easy to use extensible API for all SMS providers". Twilio discontinues its v1 API endpoint but your software only supports v1 and not v2. You decide to migrate to Plivo and everything works except for one API call that is used once every 3 months.
And on and on and on...see the point?
> I am asking you to provide to me exactly on what we agreed upon in our contract.
Great, now the developer not only has to be a "good developer" but also an expert in contract writing (or has a lawyer that is). Or worse, the lawyer and developer must be completely and harmoniously in sync about product functionality and the contractually nature that you, the client, originally decided to sign the contract with. Note - In case you are unaware, software contracts are notoriously difficult to do well (see Google/Oracle debacle).
> If I buy a product I expect that product to perform as was promised. If it does not and the manufacturer refuses to work with me then it's a breach or contract.
I think you're going to find the more and more you explain your position the more and more you'll see that "why is this so hard" is truly...hard.
Those aren't manufacturing defects. They are all changes of dependencies that should be made clear in the contract anyways.
I have to admit that i am not too familiar with how Linux versioning works (more of a windows environment guy), but if I buy software that was developed for windows 7, that stops working on windows 10 then it's obviously not a manufacturing defect. That's me changing to OS to a none supported one. I believe that "System Requirements" is a fair section for software to have.
And assuming that i was informed before hand that the software depends on Twilio API version X.Y i won't see those changes as a manufacturing defect either.
In my opinion, manufacturing defects are things such as:
- the software corrupting data during normal operation - the software behaving differently than specified in the documentation - the software not handling edge cases correctly
> easy to use extensible API for all SMS providers
Don't ever use that language within your technical/legal documents. It's fine for marketing, but when it comes to specifications always be specific. If you write something like this, but not what Providers/API in particular you are using/offering then don't be surprised if I am annoyed when your software stops working. After all I literally had no way of knowing what you supported, you didn't give me that very specific information.
I have to admit that i am not too familiar with how Linux versioning works (more of a windows environment guy), but if I buy software that was developed for windows 7, that stops working on windows 10 then it's obviously not a manufacturing defect. That's me changing to OS to a none supported one. I believe that "System Requirements" is a fair section for software to have.
And assuming that i was informed before hand that the software depends on Twilio API version X.Y i won't see those changes as a manufacturing defect either.
In my opinion, manufacturing defects are things such as:
- the software corrupting data during normal operation - the software behaving differently than specified in the documentation - the software not handling edge cases correctly
> easy to use extensible API for all SMS providers
Don't ever use that language within your technical/legal documents. It's fine for marketing, but when it comes to specifications always be specific. If you write something like this, but not what Providers/API in particular you are using/offering then don't be surprised if I am annoyed when your software stops working. After all I literally had no way of knowing what you supported, you didn't give me that very specific information.
I don't understand why you responded to those two specific examples, I simply made them up because they were two plausible cases for "the environment changes and your contract needs a whole bunch of if/then statements to allow for them under the rules you've created to be successful and find so simple". I'm still amazed your not getting the point yet, which is:
- Think really hard about every possible permutation license software could encounter and then multiply that by 100x and that's how you would need to structure this imaginary contract you keep referring to.
- Said contract would be expensive and require a very technically knowledgable lawyer (see my reference to Google/Oracle which you conveniently glossed over). In case you are unaware: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
It's mind boggling to me that software developers (which, based on your language, I presume you are) understand the intricacies and complexities of software development, yet are so hand wavy about the realities of busy "see its just so easy...".
- Think really hard about every possible permutation license software could encounter and then multiply that by 100x and that's how you would need to structure this imaginary contract you keep referring to.
- Said contract would be expensive and require a very technically knowledgable lawyer (see my reference to Google/Oracle which you conveniently glossed over). In case you are unaware: https://en.wikipedia.org/wiki/Google_LLC_v._Oracle_America,_....
It's mind boggling to me that software developers (which, based on your language, I presume you are) understand the intricacies and complexities of software development, yet are so hand wavy about the realities of busy "see its just so easy...".
I think that's entirely reasonable. I'd be expecting two years, too as my "high end" expectation.
> We're not resistant to paying, we're resistant to rent-seeking.
Yet most employers who can afford to pay developers their high salaries are rent seekers. That’s hypocrisy right there.
Yet most employers who can afford to pay developers their high salaries are rent seekers. That’s hypocrisy right there.
[deleted]
> We're not resistant to paying, we're resistant to rent-seeking
So by your definition, a stable salary writing software is a form of “rent seeking” in open source, but totally acceptable as a job?
So by your definition, a stable salary writing software is a form of “rent seeking” in open source, but totally acceptable as a job?
> What I find truly bizarre is how many software engineers, [...] are so resistant to paying anything for tools that make their job easier and faster. It blows my mind.
What I find truly bizarre is why you bring this up in this discussion. The mentionned link is about a developper who switch from one proprietary to an open source software, both being free as in free beer.
The rest of your post is about being a fanboy of Jetbrains. Sure you may like it and are free to do so but I don't see what is difficult to understand that other people may have different preferences.
> The amount of time I saw people spend on tuning, fixing, tinkering, debugging and otherwise modifying their .vim or .emacs files
Are you making things up?
I only tinker with my neovim init file whem I want to add a plugin, which is adding one vim-plug line and command and don't take much more time than adding a plugin for another IDE.
Most people have their preferred settings that they migrate from one machine to another. I used an example vim init file from someone else and only did a handful of changes that took me probably less than 10-15 minutes over as many years.
What I find truly bizarre is why you bring this up in this discussion. The mentionned link is about a developper who switch from one proprietary to an open source software, both being free as in free beer.
The rest of your post is about being a fanboy of Jetbrains. Sure you may like it and are free to do so but I don't see what is difficult to understand that other people may have different preferences.
> The amount of time I saw people spend on tuning, fixing, tinkering, debugging and otherwise modifying their .vim or .emacs files
Are you making things up?
I only tinker with my neovim init file whem I want to add a plugin, which is adding one vim-plug line and command and don't take much more time than adding a plugin for another IDE.
Most people have their preferred settings that they migrate from one machine to another. I used an example vim init file from someone else and only did a handful of changes that took me probably less than 10-15 minutes over as many years.
> Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way.
- Worse performance
- Worse plugin ecosystem
- No LSP support
Also, their stance on supporting other ecosystems. While I completely understand their standpoint as a business, I prefer VSCode team's approach to this.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
https://discuss.kotlinlang.org/t/official-support-for-visual...
> Why are so many resistant so other people earning a living particularly when the payoff (ie time-saved) is so easily quantifiable?
Is it, though?
- Worse performance
- Worse plugin ecosystem
- No LSP support
Also, their stance on supporting other ecosystems. While I completely understand their standpoint as a business, I prefer VSCode team's approach to this.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
https://discuss.kotlinlang.org/t/official-support-for-visual...
> Why are so many resistant so other people earning a living particularly when the payoff (ie time-saved) is so easily quantifiable?
Is it, though?
I use and pay a subscription for entire jetbrains suite. That said - vscode is miles better for JS/TS development IMO. In that world I don't want the full fat IDE experience because :
- it's slower - even some basic things like terminal rendering feels better/faster in vscode
- ecosystem is developing independently and so fast that IDE support can't keep up
- everyone else is using CLI centric workflows so it's maintained and tested
- it's slower - even some basic things like terminal rendering feels better/faster in vscode
- ecosystem is developing independently and so fast that IDE support can't keep up
- everyone else is using CLI centric workflows so it's maintained and tested
> What I find truly bizarre is how many software engineers, who are aware of how much they earn and how long it really takes to make software, are so resistant to paying anything for tools that make their job easier and faster.
The first time I paid for a fancy IDE, it ran on an Apple IIgs in the late 80s. It was the first of many. Unfortunately, commerical IDEs and editors go out of business constantly. The rare survivors, like BBEdit, tend to be limited to a single OS.
Around 1997, I figured out what I want out of an editor:
- Supports every language and text file format I'll need.
- Runs on every desktop OS.
- Customizable, and scriptable using an industry-standard language.
- Will still be around in 20 years.
Emacs met these requirements, and I used it for over 20 years. A few years ago, I switched to VS Code.
I don't buy commercial editors because they don't provide the key features I want. And I don't trust them to stick around.
The first time I paid for a fancy IDE, it ran on an Apple IIgs in the late 80s. It was the first of many. Unfortunately, commerical IDEs and editors go out of business constantly. The rare survivors, like BBEdit, tend to be limited to a single OS.
Around 1997, I figured out what I want out of an editor:
- Supports every language and text file format I'll need.
- Runs on every desktop OS.
- Customizable, and scriptable using an industry-standard language.
- Will still be around in 20 years.
Emacs met these requirements, and I used it for over 20 years. A few years ago, I switched to VS Code.
I don't buy commercial editors because they don't provide the key features I want. And I don't trust them to stick around.
$100 for a tool that enables my career is completely worth it. There are two issues:
* Freedom - my workflow is centered around modifying tools to suit my use case. OSI open source makes this easier sometimes.
* Ubiquity - I detest spending time updating license keys, figuring out if that key works with the version I downloaded, finding out that new-feature isn't available in the version I paid for, or wrangling with how many computers my license will allow me to run the tool on. If the trappings and enforcement of monetization weren't present, I'd spend a lot more money on software tools.
Aside: I worked on a team managing build infra at one point, and just getting license servers and license files set up so that CI could leverage proprietary tools was a major, sustained effort. I know personal tooling is more lightweight, but the same dynamics are present.
So my investment in tuning Emacs feels to me like an actual investment: I've gotten really good at tuning Emacs for various uses, and the time I spent on that has made me a more effective engineer in some ways. I bring Emacs to every job I work and even if I end up using JetBrains for e.g. Android dev, I still have Emacs in my pocket for text editing, Magit, org mode, dired, and shells/terms. I don't feel the same way about time spent managing licenses for proprietary tooling, or even learning this particular company's git tooling; I just keep using Magit. Maybe others don't feel as strongly that their preferred tooling be "everywhere", but I really value it.
* Freedom - my workflow is centered around modifying tools to suit my use case. OSI open source makes this easier sometimes.
* Ubiquity - I detest spending time updating license keys, figuring out if that key works with the version I downloaded, finding out that new-feature isn't available in the version I paid for, or wrangling with how many computers my license will allow me to run the tool on. If the trappings and enforcement of monetization weren't present, I'd spend a lot more money on software tools.
Aside: I worked on a team managing build infra at one point, and just getting license servers and license files set up so that CI could leverage proprietary tools was a major, sustained effort. I know personal tooling is more lightweight, but the same dynamics are present.
So my investment in tuning Emacs feels to me like an actual investment: I've gotten really good at tuning Emacs for various uses, and the time I spent on that has made me a more effective engineer in some ways. I bring Emacs to every job I work and even if I end up using JetBrains for e.g. Android dev, I still have Emacs in my pocket for text editing, Magit, org mode, dired, and shells/terms. I don't feel the same way about time spent managing licenses for proprietary tooling, or even learning this particular company's git tooling; I just keep using Magit. Maybe others don't feel as strongly that their preferred tooling be "everywhere", but I really value it.
> What I find truly bizarre is how many software engineers, who are aware of how much they earn and how long it really takes to make software, are so resistant to paying anything for tools that make their job easier and faster. It blows my mind.
How long have you worked in software, or any industry? "Pay for this thing that will make your job easier" is the Big Lie of software. ~Half of the time it becomes "makes your job harder" (often imperceptibly without hindsight!) because the product is primarily designed to lock-in paying enterprise customers and only secondarily to provide them with a productivity-boosting service.
It is rational for people working in the industry to be skeptical of such claims.
How long have you worked in software, or any industry? "Pay for this thing that will make your job easier" is the Big Lie of software. ~Half of the time it becomes "makes your job harder" (often imperceptibly without hindsight!) because the product is primarily designed to lock-in paying enterprise customers and only secondarily to provide them with a productivity-boosting service.
It is rational for people working in the industry to be skeptical of such claims.
It seems to me that reasonably priced software is quite rare. To me and IDE is basically a fancy text editor and I've never really found one that really spoke to me (coding is not my primary job though), so $100/year seems steep for what looks like mostly a text editor to me. (Side note for all the vim/emacs wars, I'm quite satisfied with gedit). It also seems like the era of buying software is over; now it is a rent that you pay and all the other rents I must pay are going up so I'm not looking for any other.
So I see the appeal of free software (as in liberty and as in beer) - I recently switched a work machine over to pure Debian and it's a breath of fresh air. No proprietary container based installs, no advertising/telemetry built in, and I can choose a desktop environment that I like with some idea that it won't randomly move GUI elements around and change things for the sake of change because some product manager or UX engineer or other needs to make said change to justify their over-inflated salary. LXDE still looked like the LXDE I remember and the same goes for Cinnamon and MATE.
So I see the appeal of free software (as in liberty and as in beer) - I recently switched a work machine over to pure Debian and it's a breath of fresh air. No proprietary container based installs, no advertising/telemetry built in, and I can choose a desktop environment that I like with some idea that it won't randomly move GUI elements around and change things for the sake of change because some product manager or UX engineer or other needs to make said change to justify their over-inflated salary. LXDE still looked like the LXDE I remember and the same goes for Cinnamon and MATE.
This doesn't seem to have anything to do with the article or its author, who switched not because of cost but because of unavoidable telemetry and tracking.
What I find truly bizarre is how many virtual monopoly owning companies, rather than concentrate on maximising the financial gains available from their enviable dominance of a market segment, instead focus on miserablising user experience and instrusively degrading their paying customers' sense of ownership and enjoyment in using the software they produce.
What I find truly bizarre is how many virtual monopoly owning companies, rather than concentrate on maximising the financial gains available from their enviable dominance of a market segment, instead focus on miserablising user experience and instrusively degrading their paying customers' sense of ownership and enjoyment in using the software they produce.
> Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way. For individual use, most of them are <$100/year.
After a particularly bad tooling week (js supply chain problems, plugin problems and more than the usual amount of DB changes) Our dev team made the unanimous call to move require all developers to use Jetbrains IDEs instead of the mix of VSCode, Emacs and whatever else... Our codebase is Python, Go and Javascript, and data is stored in Postgres, so we use Goland, PyCharm, WebStorm and Datagrip regularly. We also started using the awesome Micro editor when we need something that can be installed on a remote because it's key bindings are identical to JetBrains...
A few thoughts:
1. We all picked up 2-3 hours per week of time we were spending pounding plugins on Emacs and VSCode into shape. There was a lot more fiddling going on than we thought.
2. The debugger in JetBrains IDEs is top notch. Debuggers are underrated, and bad debuggers make using print and over-logging seem like the best option.
3. When we want to do something new, (containers, notebooks, etc...) it is almost always supported, and there are not 100 incomplete plugins to sort out (both Emacs and VSCode have this issue).
4. We're doing things the same way, which sometimes really pays off. For example, instead of a mix of PostMan, python scripts, restclient, and bashified curl for making api requests, we just use the client in the IDE... which means we can share them.
5. Datagrip and the database tools in the IDEs are incredibly useful.
Ok, so the payoff: By the end of the second week, we were over the learning curve, and the payoff came in the third week: a total of 16 hours of developer time not spent on twiddling with Emacs, vim, Sublime and VSCode. That time savings paid for the subscription for the year.
After a particularly bad tooling week (js supply chain problems, plugin problems and more than the usual amount of DB changes) Our dev team made the unanimous call to move require all developers to use Jetbrains IDEs instead of the mix of VSCode, Emacs and whatever else... Our codebase is Python, Go and Javascript, and data is stored in Postgres, so we use Goland, PyCharm, WebStorm and Datagrip regularly. We also started using the awesome Micro editor when we need something that can be installed on a remote because it's key bindings are identical to JetBrains...
A few thoughts:
1. We all picked up 2-3 hours per week of time we were spending pounding plugins on Emacs and VSCode into shape. There was a lot more fiddling going on than we thought.
2. The debugger in JetBrains IDEs is top notch. Debuggers are underrated, and bad debuggers make using print and over-logging seem like the best option.
3. When we want to do something new, (containers, notebooks, etc...) it is almost always supported, and there are not 100 incomplete plugins to sort out (both Emacs and VSCode have this issue).
4. We're doing things the same way, which sometimes really pays off. For example, instead of a mix of PostMan, python scripts, restclient, and bashified curl for making api requests, we just use the client in the IDE... which means we can share them.
5. Datagrip and the database tools in the IDEs are incredibly useful.
Ok, so the payoff: By the end of the second week, we were over the learning curve, and the payoff came in the third week: a total of 16 hours of developer time not spent on twiddling with Emacs, vim, Sublime and VSCode. That time savings paid for the subscription for the year.
> Our dev team made the unanimous call to move require all developers to use Jetbrains IDEs
Wow, it'd be time to look for a new job.
I think having a blessed option and understanding of "use what you want but don't let it affect deliverables" is best.
Wow, it'd be time to look for a new job.
I think having a blessed option and understanding of "use what you want but don't let it affect deliverables" is best.
>Wow, it'd be time to look for a new job.
Everyone on the team agreed. If one person had said no, we would not have made the jump.
> I think having a blessed option and understanding of "use what you want but don't let it affect deliverables" is best.
That's kind of how it worked out for us. We didn't ban emacs or vs code, we just all agreed we'd go Jet Brains first and mostly... and for the more senior of us (me especially), go out of the comfort zone and learn the new tool.
Everyone on the team agreed. If one person had said no, we would not have made the jump.
> I think having a blessed option and understanding of "use what you want but don't let it affect deliverables" is best.
That's kind of how it worked out for us. We didn't ban emacs or vs code, we just all agreed we'd go Jet Brains first and mostly... and for the more senior of us (me especially), go out of the comfort zone and learn the new tool.
While I've never worked anywhere that enforced the IDE, I can see the appeal.
Problems like linting and formatting working differently for different developers because they're using different tools, not updating settings correctly because their IDE uses a different settings file. Junior developers struggling to find people to help them because everyone's using their own toolchain.
It's not all just about deliverables.
Problems like linting and formatting working differently for different developers because they're using different tools, not updating settings correctly because their IDE uses a different settings file. Junior developers struggling to find people to help them because everyone's using their own toolchain.
It's not all just about deliverables.
> We all picked up 2-3 hours per week
Why every week? Usually you do it once and adapt when you need a new plugin, which is usually a matter of minutes.
Why every week? Usually you do it once and adapt when you need a new plugin, which is usually a matter of minutes.
> I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way.
I'm not sure if you mean this literally, but I think that's a bit of an exaggeration. I mentioned this the other day here [1], but for whatever reason, I've been completely unable to get Intellij to properly allow me to work on a remote codebase for my job. Despite my company giving me access to the Ultimate edition, the 2021 version of Intellij just flat out refused to connect when I tried to use the ssh plugin, and the 2022 edition's beta of a new ssh feature worked for about a week before somehow getting into a state where it would reconnect every 5 seconds or so and scroll me to the top of whatever file I was trying to edit. I'm sure there are ways to get it to work, but given that VS Code just worked the first time I set it up and never really got in my way, I have no motivation to spend more than a few minutes trying to get Intellij working before just giving up and going back to VS Code.
I think if you see behavior that seems so obviously "wrong" to you, it's worth giving people the benefit of the doubt and actually trying to see _why_ people do things that way before just dismissing them as irrational. I wouldn't be surprised if you've actually talked to people who might have experiences like this that could explain the discrepancy, but if you start the conversation so dismissively, most people aren't going to bother trying to share their experiences with you.
[1]: https://news.ycombinator.com/item?id=31669461
I'm not sure if you mean this literally, but I think that's a bit of an exaggeration. I mentioned this the other day here [1], but for whatever reason, I've been completely unable to get Intellij to properly allow me to work on a remote codebase for my job. Despite my company giving me access to the Ultimate edition, the 2021 version of Intellij just flat out refused to connect when I tried to use the ssh plugin, and the 2022 edition's beta of a new ssh feature worked for about a week before somehow getting into a state where it would reconnect every 5 seconds or so and scroll me to the top of whatever file I was trying to edit. I'm sure there are ways to get it to work, but given that VS Code just worked the first time I set it up and never really got in my way, I have no motivation to spend more than a few minutes trying to get Intellij working before just giving up and going back to VS Code.
I think if you see behavior that seems so obviously "wrong" to you, it's worth giving people the benefit of the doubt and actually trying to see _why_ people do things that way before just dismissing them as irrational. I wouldn't be surprised if you've actually talked to people who might have experiences like this that could explain the discrepancy, but if you start the conversation so dismissively, most people aren't going to bother trying to share their experiences with you.
[1]: https://news.ycombinator.com/item?id=31669461
I can afford lots of things, doesn't mean I'm going to buy them.
What's bizarre about that? The only Bizarre Attitude I see here is yours: that there exists a best option and why aren't more people taking it?
There's no such thing as a "Best Option".
What's bizarre about that? The only Bizarre Attitude I see here is yours: that there exists a best option and why aren't more people taking it?
There's no such thing as a "Best Option".
> Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way. For individual use, most of them are <$100/year.
They just aren't, I would not switch to Jetbrains from VSCode even if it was free. It's not a question of pricing and Jetbrains themselves started to realise it since they are building some VSC clone (forgot the name right now)
They just aren't, I would not switch to Jetbrains from VSCode even if it was free. It's not a question of pricing and Jetbrains themselves started to realise it since they are building some VSC clone (forgot the name right now)
They just are though, once you realise how much more powerful they are.
I had a collegue until recently (he was let go), who was a staunch VSCode fan that refused to use Jetbrains IDEs. His code is terrible and riddled with bugs. Most of them were even easily detected by the Jetbrains IDEs. Now I have to clean up his shitty projects.
He also spend a lot of time configuring his shitty VSCode instead of working.
Oh yeah sure they are powerful, I don't deny that but I really hate the UX and the readability. At the end of the day, I don't really want to spend time to make it usable enough to my liking.
I've tried IntelliJ for both Elixir and Clojure. While Cursive is ok, I can confidently say that the vscode Elixir support is far, far better, and in Cursive vs Cider I'd take Cider any day.
Yeah, if your writing Kotlin/Java IntelliJ is a no-brainer, but for many of us the situation is much more nuanced.
Yeah, if your writing Kotlin/Java IntelliJ is a no-brainer, but for many of us the situation is much more nuanced.
Expecting a IDE to fix someone's terrible code riddle with bugs non sequitur. What programming language was this?
Their new VSC alternative name is fleet and I don't think they confirmed it will be free like VSCode though.
Thanks for the name, I completely forgot about it. I'm totally fine paying for it if it's nice, it's just that I prefer something similar to VSCode rather than Jetbrains IDEs.
Are you refering to free or free? Paying money I don't mind, but being non-free would be a big drawback.
You're really missing an important factor of software development which is making things accessible to all walks of life. I simply prefer open source because it doesn't exclude specific classes of people because of money. Imagine a future where only rich people and those from wealthy families get access to the good development tools to help them get richer, while poor developers and those not from a wealthy family struggle to even get access to basic tooling, or have to exchange their personal information and rights in exchange.
Fortunately, many people in software are not simply money worshipers and envision a future where money isn't the priority in building a better world.
Fortunately, many people in software are not simply money worshipers and envision a future where money isn't the priority in building a better world.
Who's to say we aren't productive with our chosen editors?
I find malarkey like autocomplete to be distracting, so I use Emacs with it turned off. Because Emacs can be programmed and extended as it is used, it is way more productive to me than any "fixed function" IDE -- including Visual Studio Code[0] I could not do my job nearly as effectively in Visual Studio Code or JetBrains as I do in Emacs.
There is a perspective dependence to what the "best tool for the job" is. You are most productive in JetBrains and that is fine, but that doesn't make your colleagues less productive in their choice of editor.
[0] To extend Visual Studio Code, you have to start a new Node TypeScript project that uses VSCode's cumbersome API, compile it, test it in an "Extension Host", bundle it in a .vsix and then, at long last, you can use it in your regular editor. It's clear that Visual Studio Code's designers did not want end users programming their editor, let alone programming and using it at the same time. As a VSCode end user, the happy path is to select from pre-made extensions in Microsoft's extension catalog.
I find malarkey like autocomplete to be distracting, so I use Emacs with it turned off. Because Emacs can be programmed and extended as it is used, it is way more productive to me than any "fixed function" IDE -- including Visual Studio Code[0] I could not do my job nearly as effectively in Visual Studio Code or JetBrains as I do in Emacs.
There is a perspective dependence to what the "best tool for the job" is. You are most productive in JetBrains and that is fine, but that doesn't make your colleagues less productive in their choice of editor.
[0] To extend Visual Studio Code, you have to start a new Node TypeScript project that uses VSCode's cumbersome API, compile it, test it in an "Extension Host", bundle it in a .vsix and then, at long last, you can use it in your regular editor. It's clear that Visual Studio Code's designers did not want end users programming their editor, let alone programming and using it at the same time. As a VSCode end user, the happy path is to select from pre-made extensions in Microsoft's extension catalog.
This is something I wonder about all the time. I think there a number of reasons:
1. Ideological - probably can't reason with these people
2. Preference for small tools vs. one monolithic tool - less efficient, but I can understand it
3. Ignorance - Many younger/inexperienced developers never learned an IDE, and genuinely do not understand what they are missing
4. Cost - not a concern for most of us, but for minors, students, or developers in India, China, and other developing countries, this is a huge reason that drives ubiquity of VSCode
5. Reduced friction/ubiquity - See 4. Basically, people are already used to it when they get a well-paying job and in theory could use JetBrains IDEs
6. Performance - See 4 again. Not really an issue unless you're on old hardware (especially given that VSCode performs poorly, can't handle large files, etc.)
In conclusion, I think there are some legitimate reasons, but your larger point still stands.
1. Ideological - probably can't reason with these people
2. Preference for small tools vs. one monolithic tool - less efficient, but I can understand it
3. Ignorance - Many younger/inexperienced developers never learned an IDE, and genuinely do not understand what they are missing
4. Cost - not a concern for most of us, but for minors, students, or developers in India, China, and other developing countries, this is a huge reason that drives ubiquity of VSCode
5. Reduced friction/ubiquity - See 4. Basically, people are already used to it when they get a well-paying job and in theory could use JetBrains IDEs
6. Performance - See 4 again. Not really an issue unless you're on old hardware (especially given that VSCode performs poorly, can't handle large files, etc.)
In conclusion, I think there are some legitimate reasons, but your larger point still stands.
I was a jetbrains guy until I discovered the vim/neovim ecosystem. Yes, configurling vim takes time but 1.its fun 2. I can fine tune it to my specific work flows in ways simply not achievable with Idea or any other editor.
After configuration is finished, the actual time it takes to do my work is comparable with a full fledged ide. It's probably even faster, considering vim loads faster and also forces you to use the keyboard for everything.
Imagine being on your deathbed thinking: "Configuring vim was so fun. Totally worth it". I sometimes feel that most people on this forums are under 24 years of age. So sad to read these comments. So much to do, so many interesting things.... but people enjoy configuring text editors...
If people enjoy it, why do you think they would regret it later? It sounds like you just don't enjoy it, which is ok.
A lot of regret actually comes from enjoying something and then later realising that it was stupid and a waste of time. Time that you would have liked to spend on a more useful endeavour.
A lot of your personal regret might come from that. I think it's important to note that there are many people who can look back fondly at times they were simply enjoying themselves, even if that time was not strictly 'useful'.
The joyful days of configuring vim. You are trolling me at this point.
Guilty as charged ;)
But still beter than being on a deathbed thinking: "Spending time on internet telling people I know nothing about what they should do was totally worth it".
But still beter than being on a deathbed thinking: "Spending time on internet telling people I know nothing about what they should do was totally worth it".
I posit that the reason is we form a lot of habits and patterns when we are younger - like high school students or college students where most of us have more time and very little money.
Some of us reassess spending patterns over time (and even there some do it more frequently than others).
So you have this spread where a part of the population is still very frugal and some part is almost price insensitive and then everything in between.
Love to hear what other folks think.
Some of us reassess spending patterns over time (and even there some do it more frequently than others).
So you have this spread where a part of the population is still very frugal and some part is almost price insensitive and then everything in between.
Love to hear what other folks think.
I love the Jetbrains IDEs and have used them for years and they'll pry CLion from my cold dead hands. I pay for a license for it. I've tried VSCode many times and always come back to CLion.
However.
JetBrains needs to consider rebuilding on something other than Java/Swing. The UI is relatively laggy. It fights with many window managers on Linux. It feels clunky compared to VS Code, from a UI POV.
However.
JetBrains needs to consider rebuilding on something other than Java/Swing. The UI is relatively laggy. It fights with many window managers on Linux. It feels clunky compared to VS Code, from a UI POV.
This is because most developers are not willing to learn even basic code completion and refactoring functions in IDE. When you write constructors and getters by hand in Intellij Idea, chances are you won’t pay for that.
Vim has auto-completion and snippets. I don't use VSCode, but I'm pretty sure it does too. So what's the point of paying for them?
> What I find truly bizarre is how many software engineers, who are aware of how much they earn [...] are so resistant to paying anything for tools that make their job easier and faster. It blows my mind.
The property premise that software engineers earn so much clearly holds for the USA (and some other countries), but there are a lot of countries where it is not true.
The property premise that software engineers earn so much clearly holds for the USA (and some other countries), but there are a lot of countries where it is not true.
I think developers do pay a Lot for hardware tools ( Mac / screen / custom keyboard / IOTs they will never play with and so on ). They just don't pay much for software tools.
Marketing / Sales people will not pay that much for hardware but pay a lot for software tools.
I have used modern editors. For the most part they are amazing. That being said, I always end up returning to the same old open source editor. Much of the reason can be attributed to one quality: it has been around for as long as I have been alive and it will likely be around long after I am gone. This means that I am continually building upon prior skills, rather than tossing them out the window each time a new fad comes along or a vendor goes out of business. Incidentally, this is also why I don't see the payoff from commercial editors as being easily quantifiable. They may do a rather good job at reducing the learning curve, but they cannot eliminate it.
I'm not interested in paying to have my computing freedom violated. If I pay for software, I don't get software, I get a license which is a limited conditional permission to use the software, a privilege that can be taken away and also comes bundled with a stack of rules and prohibitions nobody really cares about.
All proprietary software deserves the git treatment where people eventually get fed up with it and replace it with superior free software, thereby permanently enriching the world. We need to understand the factors that enabled such a development and somehow incentivize them.
All proprietary software deserves the git treatment where people eventually get fed up with it and replace it with superior free software, thereby permanently enriching the world. We need to understand the factors that enabled such a development and somehow incentivize them.
I think it's an issue with some tools being "good enough" (majority of the free ones) + the feeling where you paid for something and it feels meh (or maybe it asks for paid upgrades, etc)
I tried Sublime Text once and then never bothered later. There wasn't anything that exciting about it that I couldn't do one way or another anywhere else.
The barrier to payment is higher if the comparison with a free tool is mixed. If there was one big thing the free ones couldn't do or they were much worse then there would be a case for paying for your tools
I tried Sublime Text once and then never bothered later. There wasn't anything that exciting about it that I couldn't do one way or another anywhere else.
The barrier to payment is higher if the comparison with a free tool is mixed. If there was one big thing the free ones couldn't do or they were much worse then there would be a case for paying for your tools
I used VScode for 2 years then bought Jetbrains for 3 years, now I'm switching back to VScode. I feel vscode is getting better plus it is open source.
Does open source matter a lot? maybe. For example, Jetbrains' Teamcity is still under investigation for Solarwinds hack which is a concern, plus I think a while ago the core developers are mostly from Russia at Jetbrains. Those combined with an improved vscode made the switch for me. I mainly use vim in practice but I do need a GUI IDE once a while.
Does open source matter a lot? maybe. For example, Jetbrains' Teamcity is still under investigation for Solarwinds hack which is a concern, plus I think a while ago the core developers are mostly from Russia at Jetbrains. Those combined with an improved vscode made the switch for me. I mainly use vim in practice but I do need a GUI IDE once a while.
> Take the Jetbrains IDEs. I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way.
I just discontinued my Jetbrains subscription after 10 years or so. Now I'm using VS Code and don't miss anything. My reasons for switching to VS Code are unrelated to the costs but purely due to quality issues and missing or poorly implemented features:
1. For all Jetbrains IDEs, ISO keyboard layout with dead keys doesn't work on Ubuntu based distros. I was baffled when I found out after saying goodbye to Windows lately. When filing a bug I was asked to wade through years old pages of comments to find somewhere someone who posted a workaround that was not compatible with the Toolbox. Well, at least the support could have sent me the instructions to fix it to save me spending an hour to read those threads at Youtrack.
2. Vue 3 support was a disaster for itself. Still, Vue 3 support is very much behind the VS Code extension.
3. Same for Svelte. They are not even working on bugs / feature requests like intellisense in the templates.
4. Same for TailwindCSS. Never ending storing. Don't know and care if Jetbrains got it right by now.
5. Starting maybe 2 years ago, Jetbrains added feature for feature that were just distracting and annoying. This "run command in terminal" thingie for example. They're bloating their IDEs with new (mostly useless stuff) but don't fix essential bugs or get Webstorm back into shape.
6. Datagrip still doesn't (or maybe it does in the meantime) support SQLite STRICT TABLES (version 3.37). The simple answer from Jetbrains was: "The open source lib we're using does not support it so we don't." (Actually the lib (https://github.com/xerial/sqlite-jdbc) is currently unmaintained - another reason to be careful depending on a lib maintained by a single person.). The reply would be perfectly fine for an open source project, but not for a multi billion dollar company I as a customer had payed accumulated several thousand Euros in the last years.
I'm using mainly Go, Rust and several frontend frameworks. VS Code support for those is really good. Many things work much better in VS Code.
I just discontinued my Jetbrains subscription after 10 years or so. Now I'm using VS Code and don't miss anything. My reasons for switching to VS Code are unrelated to the costs but purely due to quality issues and missing or poorly implemented features:
1. For all Jetbrains IDEs, ISO keyboard layout with dead keys doesn't work on Ubuntu based distros. I was baffled when I found out after saying goodbye to Windows lately. When filing a bug I was asked to wade through years old pages of comments to find somewhere someone who posted a workaround that was not compatible with the Toolbox. Well, at least the support could have sent me the instructions to fix it to save me spending an hour to read those threads at Youtrack.
2. Vue 3 support was a disaster for itself. Still, Vue 3 support is very much behind the VS Code extension.
3. Same for Svelte. They are not even working on bugs / feature requests like intellisense in the templates.
4. Same for TailwindCSS. Never ending storing. Don't know and care if Jetbrains got it right by now.
5. Starting maybe 2 years ago, Jetbrains added feature for feature that were just distracting and annoying. This "run command in terminal" thingie for example. They're bloating their IDEs with new (mostly useless stuff) but don't fix essential bugs or get Webstorm back into shape.
6. Datagrip still doesn't (or maybe it does in the meantime) support SQLite STRICT TABLES (version 3.37). The simple answer from Jetbrains was: "The open source lib we're using does not support it so we don't." (Actually the lib (https://github.com/xerial/sqlite-jdbc) is currently unmaintained - another reason to be careful depending on a lib maintained by a single person.). The reply would be perfectly fine for an open source project, but not for a multi billion dollar company I as a customer had payed accumulated several thousand Euros in the last years.
I'm using mainly Go, Rust and several frontend frameworks. VS Code support for those is really good. Many things work much better in VS Code.
Actually Eclipse (and Spring Tool Suite based on Eclipse) works great. Being able to simultaneously debug several microservices in one Eclipse instance is one amazing feature.
The thing that bothers me the most about the resistance to pay for anything is that you're not spreading the love to your fellow devs/creators.
I know HN has grown so this may not be as true as before, but we're a community of builders! We should all understand the time and effort put into each of these projects. You'll tip a delivery person but won't support the people spending thousands of hours building the tools that makes your life tangibly better?
</rant>
I know HN has grown so this may not be as true as before, but we're a community of builders! We should all understand the time and effort put into each of these projects. You'll tip a delivery person but won't support the people spending thousands of hours building the tools that makes your life tangibly better?
</rant>
I think of HN to more of a community of rational people. Rational people pay for what they believe would get value to their workflow or just support a principle or an idea like open source.
I hardly can see any of that applies to Jetbrains products. many people here stated (which I agree) that Vscode and vim/emacs is better for them technically and for being open source.
I hardly can see any of that applies to Jetbrains products. many people here stated (which I agree) that Vscode and vim/emacs is better for them technically and for being open source.
I am fully willing to pay somebody for software. I just also want the software to be free (in the FSF sense).
Do I need to pay each time I want one of their updates? Or do I need to pay a subscription for support+code update?
I'm 100% game to do that but I want to own what I get and I want the freedom to do with it what I want (within reason).
If I want to recompile the software with some change I made, port the software to some other hardware, or go dig in the source to identify a bug, I want that option. It's that plain and simple.
If the license says "no commercial use unless you pay X flat, Y subscription, or Z whatever else", that's perfectly fine with me. People already use pirated versions of proprietary software so if someone wants to use your software without paying they are going to do so.
TLDR: I'll pay pretty much whatever you want for the product provided I have the means. I just want the freedom to do with my software & hardware as I please.
Edit: I wanted to toss into this that if we want more projects to be viable open source or free software projects, we need to be willing to support the developers. If you have the means, sponsor developers even if it's only some pocket change each month.
Do I need to pay each time I want one of their updates? Or do I need to pay a subscription for support+code update?
I'm 100% game to do that but I want to own what I get and I want the freedom to do with it what I want (within reason).
If I want to recompile the software with some change I made, port the software to some other hardware, or go dig in the source to identify a bug, I want that option. It's that plain and simple.
If the license says "no commercial use unless you pay X flat, Y subscription, or Z whatever else", that's perfectly fine with me. People already use pirated versions of proprietary software so if someone wants to use your software without paying they are going to do so.
TLDR: I'll pay pretty much whatever you want for the product provided I have the means. I just want the freedom to do with my software & hardware as I please.
Edit: I wanted to toss into this that if we want more projects to be viable open source or free software projects, we need to be willing to support the developers. If you have the means, sponsor developers even if it's only some pocket change each month.
I'm a fan of Jetbrains IDEs (despite having some complaints), and use them at work regularly (and because I work in academia, I get the enterprise version free of cost). But I think of Emacs as a life-long companion-tool, something that I'll be able to use, how I like it, until I die, on pretty much any operating system, and on pretty much any hardware.
You’re entire argument is predicated on your personal preference being superior. Sorry it’s not and neither is mine; it’s entirely context dependent and individual.
I found all of the JetBrains offerings really tacky and expensive for the price. VSCode and neovim work far better for what I want and are more extensible.
I found all of the JetBrains offerings really tacky and expensive for the price. VSCode and neovim work far better for what I want and are more extensible.
Actually, I recently had to switch from CLion to VSC b/c I could not figure out how to enable rust-analyzer in the latest version of CLion. Also platform.io support is better in VSC. I love UX of interllij tho. I should say that I do agree with your main point.
I ditched VSCodium for JetBrains Rider and couldn't be happier. On the Mac Rider is miles ahead of Visual Studio (shuddering with revulsion). But no IDE will ever dissuade me from using vim. I just use them for different things.
I think that you are looking at it from the wrong perspective.
1. IDEs that are made primarily for your host operating system by who writes the operating system is basically a loss leader and is there to tie you to the host os
2. Emacs / vi / vim (full disclosure I am an Emacs user) are generally usable out of the box with no modification. Tinkering with your configuration for Emacs is for people who are experienced with Emacs and I primarily do it to make the text editor I want.
3. The actual paid solutions seem to be profitable enough for people to use but for reasons 1 and 2 will have a disadvantage to compete with them.
1. IDEs that are made primarily for your host operating system by who writes the operating system is basically a loss leader and is there to tie you to the host os
2. Emacs / vi / vim (full disclosure I am an Emacs user) are generally usable out of the box with no modification. Tinkering with your configuration for Emacs is for people who are experienced with Emacs and I primarily do it to make the text editor I want.
3. The actual paid solutions seem to be profitable enough for people to use but for reasons 1 and 2 will have a disadvantage to compete with them.
Except that Jetbrains IDE being better isn't always true.
At work, our huge C++ project makes CLion very slow..
VSCode MS Intellisense works quite badly but at least it's faster (testing the CLang extension is in my TODO list).
At work, our huge C++ project makes CLion very slow..
VSCode MS Intellisense works quite badly but at least it's faster (testing the CLang extension is in my TODO list).
Corporate expense processes are a pita. For critical applications like an IDE its not a problem, but for smaller one off tools it's usually more effort then it's worth to use paid software.
> What I find truly bizarre is how many software engineers, who are aware of how much they earn and how long it really takes to make software, are so resistant to paying anything for tools that make their job easier and faster. It blows my mind.
I agree. I'm always surprised at what technical people aren't willing to pay for.
I think I used to be like this though. I used to really enjoy playing with my tools and learning about everything. Now that I'm older, I just want to get the job done, then go outside and play at the park or something.
I agree. I'm always surprised at what technical people aren't willing to pay for.
I think I used to be like this though. I used to really enjoy playing with my tools and learning about everything. Now that I'm older, I just want to get the job done, then go outside and play at the park or something.
You’re 100% right.
Developers are no different than other humans. Lazy, indifferent, unappreciative, self-absorbed…
Sublime Text is a perfect example.
It’s a travesty with as popular as that editor was that developers would literally use it for work and for personal projects but refuse to pay for what everyone agreed at the time was the best tool for those not using IDE’s.
It pissed me off to the point that anytime I paired with someone and the SublimeText popup showed, I’d ask them to pay the $40 or whatever was being asked.
Developers are no different than other humans. Lazy, indifferent, unappreciative, self-absorbed…
Sublime Text is a perfect example.
It’s a travesty with as popular as that editor was that developers would literally use it for work and for personal projects but refuse to pay for what everyone agreed at the time was the best tool for those not using IDE’s.
It pissed me off to the point that anytime I paired with someone and the SublimeText popup showed, I’d ask them to pay the $40 or whatever was being asked.
[deleted]
Not fair! Open-source, shareware, public-domain, freeware - been touted for decades now. But folks buy into all that and suddenly they're 'resistant to other people earning a living'.
Or I interpreted that wrong, and it's supposed to be a criticism of open-source? Then I agree. Open-source is a pox on responsible and reliable software, cannibalizing good software by offering free, bad software.
Or I interpreted that wrong, and it's supposed to be a criticism of open-source? Then I agree. Open-source is a pox on responsible and reliable software, cannibalizing good software by offering free, bad software.
> For individual use, most of them are <$100/year.
Except as a developer you need one app, then another, and another… soon enough you’ll be paying 10 x 50$/year.
And paying a sub for software is repugnant to me. I bought FontAwesome 5 while it was in KickStarter, it’s no longer updated (it’s now version 6), but at least I can still fully use the thousands of icons I paid for.
tldr: way too damn expensive.
Except as a developer you need one app, then another, and another… soon enough you’ll be paying 10 x 50$/year.
And paying a sub for software is repugnant to me. I bought FontAwesome 5 while it was in KickStarter, it’s no longer updated (it’s now version 6), but at least I can still fully use the thousands of icons I paid for.
tldr: way too damn expensive.
Yeah exactly. They are just too expensive. I'm happy to pay for things that I believe are worth it, but especially with yearly subscriptions I don't see the value equation meeting it for these IDEs.
>are so resistant to paying anything
>Take the Jetbrains IDEs
Because most of the modern day software engineers now works on Web related technology. And somehow everything on the Web has to be free or Open Source.
It is much easier to sell IDE or paid for softwares to embedded or system programming developers, or basically any developers which doesn't have anything to do with the Web.
>Take the Jetbrains IDEs
Because most of the modern day software engineers now works on Web related technology. And somehow everything on the Web has to be free or Open Source.
It is much easier to sell IDE or paid for softwares to embedded or system programming developers, or basically any developers which doesn't have anything to do with the Web.
[deleted]
Software engineers know that it's creating new software that is expensive, not copying it. Why not give copies away for free when you satisfied the need that led to the software being written? Even microsoft now understands that it makes more sense to write software to better sell services than to try to sell software directly.
Do you use VSC extensions?
People extend the web-based editor to make it easier to build web applications and share those tools on the web. Using a web-based editor to build web applications is a self-reinforcing, positive loop.
I can see why people who aren't building web apps or aren't using extensions are confused why so many people prefer VSCode.
People extend the web-based editor to make it easier to build web applications and share those tools on the web. Using a web-based editor to build web applications is a self-reinforcing, positive loop.
I can see why people who aren't building web apps or aren't using extensions are confused why so many people prefer VSCode.
It really is bizarre, specially because it doesn't make sense in terms of money.
They prefer to spend dozens of hours seeking, testing and tweaking free/gratis products (in some cases their hour worth more than $100/h), but they don't want to pay $100/year in a product that will save them dozens of hours.
They prefer to spend dozens of hours seeking, testing and tweaking free/gratis products (in some cases their hour worth more than $100/h), but they don't want to pay $100/year in a product that will save them dozens of hours.
Jetbrains is a half-good example. A lot of stuff that was before opensource was close-sourced by Jetbrains and now their support for it is terrible.
I.E. Terraform plugin. Stopped working past 1.0.11 and its half a year without an update.
So yea. Ppl ARE willing to pay for stuff that „works”.
I.E. Terraform plugin. Stopped working past 1.0.11 and its half a year without an update.
So yea. Ppl ARE willing to pay for stuff that „works”.
Unfortunately for the paid IDEs, even the accessibility for screen readers is much better in VSC.
[deleted]
I'll flip the script, why are you so worried about other people choosing editors like vim and emacs? Lots of people don't struggle. Lots of people don't mind a extra few hours for open source solution as it fits their life choices.
To me, IntelliJ IDEs feel clunky, slow, feature bloated, and messy. I did pay a couple times for AppCode, but eventually stopped doing that. VSCode on the other hand feels lightweight and fast. I use it exactly _because_ I value my time.
Personal use is a different question, but if my employer doesn't pay for it I'm not buying software to use for their benefit. Any a lot of employers go huh, a free one eh? Use that.
Don't assume people who code are all silicon valley funny money devs. Instead assume they're a moderate income to broke, that's a bigger userbase.
There's also the issue of signing in or applying a licence file on a system owned by someone else. In some environments this simply isn't allowed.
Actually making the purchase can also be a nightmare.
I’m at an academic research institute, so I haven’t hit this problem with JetBrains (free licenses—thanks!), but there are lots of other products where spending $15 to save an hour is a no-brainer, but spending $15 + two hours of arguing with purchasing over whether it’s a “legitimate business purpose” is…also a no brainer.
I’m at an academic research institute, so I haven’t hit this problem with JetBrains (free licenses—thanks!), but there are lots of other products where spending $15 to save an hour is a no-brainer, but spending $15 + two hours of arguing with purchasing over whether it’s a “legitimate business purpose” is…also a no brainer.
Jetbrains does quite a bit of telemetry as well, particularly on starter versions. This has made me hesitate, until I get an outbound firewall set up.
I mostly write C++ and I would love to use CLion, but my employer won’t pay for the license fees, so my choices are VSCode or Eclipse.
> my employer won’t pay for the license fees
If it costs $200 or whatever and would clearly save you more than that in time ($200 is a few hours of developer time) then surely it's worth it. I guess the problem is that the process isn't in place to make buying CLion easy, so there'd be a lot of administrative overhead. Or no-one cares about maximising productivity. Or it's not clear to them that CLion actually is better than alternatives. Or maybe they want all developers using the same tools so any process improvements are shared.
None of those seem like great reasons tbh, but I did just make them up as part of a strawman to lambast your employer.
If it costs $200 or whatever and would clearly save you more than that in time ($200 is a few hours of developer time) then surely it's worth it. I guess the problem is that the process isn't in place to make buying CLion easy, so there'd be a lot of administrative overhead. Or no-one cares about maximising productivity. Or it's not clear to them that CLion actually is better than alternatives. Or maybe they want all developers using the same tools so any process improvements are shared.
None of those seem like great reasons tbh, but I did just make them up as part of a strawman to lambast your employer.
Proprietary tools are too big of a risk of going belly up, or not being maintained.
I'd rather say instead of paying money they should spend time to master their tools. I don't see musicians complaining about learning their instrument.
Creative Cloud.
I went backwards, from VS Codium to VS Code, because VS Codium does not support all extensions, like PyLance or Remote - SSH/containers.
I like freedom, but I like getting things done more.
I like freedom, but I like getting things done more.
It might be worth contacting these extensions' creators. If you already have the `.vsix` file for the VSCode marketplace, publishing to open-vsix is really super simple (create an account once, get a token, add a few lines to your publish script, e.g. https://github.com/prisma/language-tools/blob/94e4cd612d03ef...). Some just do not know about it.
PyLance and the remote extensions are developed by Microsoft. They intentionally do not work with the open source editor.
Have you actually tried installing PyLance in VS Codium? I have not and also do not know if it works. But PyLance is available in https://open-vsx.org/extension/ms-python/python and it seems there are no license issues.
Oh, I did not connect these dots.
Shucks.
Shucks.
I just did the same thing literally yesterday for the same reason. Disabled telemetry and hoping for the best.
I was considering switching and looking into Codium and then saw this comment. I'm not going without Remote-SSH or PyLance.
> I was increasingly getting upset about their extension marketplace, where there is an increased number of extensions starting to sell pro versions of the extensions we used for free.
I'm not familiar with any particularly egregious examples, but I don't find "developer wants to sell software" all that outrageous.
I'm not familiar with any particularly egregious examples, but I don't find "developer wants to sell software" all that outrageous.
It’s a real problem. GitLens[0] comes to mind, which used to be a decent free extension, but now gives me flashbacks to the shareware nag screens of old.
I’m also not against selling software on principle. Downgrading a free piece of software into a demo with an auto-update feels shady, however.
[0] https://marketplace.visualstudio.com/items?itemName=eamodio....
I’m also not against selling software on principle. Downgrading a free piece of software into a demo with an auto-update feels shady, however.
[0] https://marketplace.visualstudio.com/items?itemName=eamodio....
I have been using GitLens for years, and didn't even know they had a paid version. Where have they been "Nagging" that I've just never seen?
Right next to your terminal should be a tab called "Gitlens: Visual File History". I do not want to argue whether its contents qualify as nagging but it might be what OP is referring to.
See now im in this predicament where I like paying for things so people don't starve, but the thing they're charging for is something I don't care about or use. Now I'm in this weird spot where I like the tool and would like to use it, but I feel like I'm freeloading when I could be paying, but I don't want the part that costs money, so I just uninstall.
Oh, I never use the built-in terminal, and obviously never noticed or clicked on the extra heading (which seems easily hidden with right click).
This also doesn't seem to come under "nagging" for me. To me, that'd be something like, a popup while using or trying to click through a commit reference (which would almost certainly earn it an instant uninstall).
This also doesn't seem to come under "nagging" for me. To me, that'd be something like, a popup while using or trying to click through a commit reference (which would almost certainly earn it an instant uninstall).
Flashbacks?
> Does this affect existing features? > > No, the introduction of GitLens+ has no impact on existing GitLens features, so you won't lose access to any of the GitLens features you know and love. In fact, we are heavily investing in enhancing and expanding the GitLens feature set. Creating an account simply gives you access to a subset of new features that will enable you to get even more out of Git in VS Code!
I haven’t used it and only heard of it last week, but the extension’s page you linked to seems decent enough for me to try it out.
> Does this affect existing features? > > No, the introduction of GitLens+ has no impact on existing GitLens features, so you won't lose access to any of the GitLens features you know and love. In fact, we are heavily investing in enhancing and expanding the GitLens feature set. Creating an account simply gives you access to a subset of new features that will enable you to get even more out of Git in VS Code!
I haven’t used it and only heard of it last week, but the extension’s page you linked to seems decent enough for me to try it out.
I’m sure the thing you quoted is technically true, the existing features are still there somewhere. But it’s not a great experience if some of the most prominent buttons in the VS Code UI now open the GitKraken account page. YMMV; I personally found this very “in your face” and unusable.
can you elaborate?
"I made something people seem to like, hopefully it can help feed my family" sounds more like a wonderful success story rather than shady (depending on target audience of course but that's the part I'd like to understand better rather than make assumptions)
"I made something people seem to like, hopefully it can help feed my family" sounds more like a wonderful success story rather than shady (depending on target audience of course but that's the part I'd like to understand better rather than make assumptions)
Intrseting that the Gitlens code repo is under the gitkraken org. Guess they took them over?
Gitlens is the most popular example, I guess?
I started using vim 13 years ago. Editors come. Editors go. Vim remains.
This. And actually only up until a while ago did my co-workers still think using Vim was just some weird flex. Then a live coding session which was not about Vim at all I did somehow showcased how fast I was able to be in Vim, now everyone is interested in obtaining the superpower.
That being said I'm still extremely grateful for what Microsoft has done in standardising things like LSP, DAP, etc. It changed the game for Vim, Emacs, Kakoune, not to mention new players like Helix.
That being said I'm still extremely grateful for what Microsoft has done in standardising things like LSP, DAP, etc. It changed the game for Vim, Emacs, Kakoune, not to mention new players like Helix.
Absolutely.
On a tangential note, "Your problem with vim is that you don't grok vi" continues to be a favourite read: https://gist.github.com/nifl/1178878
On a tangential note, "Your problem with vim is that you don't grok vi" continues to be a favourite read: https://gist.github.com/nifl/1178878
Thank you, I might give vi another go.
Btw, for reading, raw version is better: https://gist.githubusercontent.com/nifl/1178878/raw/2a20bba8...
Btw, for reading, raw version is better: https://gist.githubusercontent.com/nifl/1178878/raw/2a20bba8...
the problem isn't the process of using vim. I like that part. The part i dislike is the ecosystem of plugins and extension points.
Yes. Learning Vim has had the best ROI for my time of any other tool I've learned over the years (git comes close though). Not only is it a great general-purpose editor, but it's available on every machine I interact with.
90% of the time, I'm writing code that vim wouldn't help with, and that 10% never seems to make up for the investment cost of learning it, especially because I'd probably forget the commands between uses. However I do respect vim users.
I'm curious now. What code are you editing that vim could not help with, what tools do you use that do help with this code, and why?
I always come back to vim. Sure there are "vim mode" options for VS Code, Jetbrains products, Xcode, whatever else, but there is a speed and ergonomics to regular old vim that none of those bolted-on modes have matched yet. And with some setup you can get the same LSP features in vim that you have in VS Code today.
Interview with a VIM Enthusiast 2022: https://www.youtube.com/watch?v=9n1dtmzqnCU
"You don't really need a career once you know Vim. Vim is your career now. What's a career anyway?"
"You don't really need a career once you know Vim. Vim is your career now. What's a career anyway?"
VScode is much more than an editor. Plus, you can run it in VIM mode for editing.
Features also come but not to Vim.
I'm already paying for sublime text and a few other developer tools and I wouldn't mind paying for a tool that helps me pay my bills.
Also I like that some of these products have a free version that makes it accessible to people coming from a poor economic background. Everyone deserves an equal opportunity in my opinion.
Now my problem about big tech corps is that they are huge bullies. I want my freedom back. Freedom of not being locked in an ecosystem. Freedom to choose my tools. Freedom of not being tracked. Freedom of everyone to be in the market without being copied, acquired or overshadowed by huge companies that buy/clone/replace any product or tool with their "free of charge" poison. Freedom to stay away of "growth and engagement" bs products.
Think of the following. How viable is to live without GMAIL nowdays? Do we want vscode to become the GMAIL of code?
Also I like that some of these products have a free version that makes it accessible to people coming from a poor economic background. Everyone deserves an equal opportunity in my opinion.
Now my problem about big tech corps is that they are huge bullies. I want my freedom back. Freedom of not being locked in an ecosystem. Freedom to choose my tools. Freedom of not being tracked. Freedom of everyone to be in the market without being copied, acquired or overshadowed by huge companies that buy/clone/replace any product or tool with their "free of charge" poison. Freedom to stay away of "growth and engagement" bs products.
Think of the following. How viable is to live without GMAIL nowdays? Do we want vscode to become the GMAIL of code?
> How viable is to live without GMAIL nowdays?
Completely. In the corporate world, Microsoft is the dominant player, but on premise is still a thing, as are other ESPs. Gmail is nowhere near as dominant as people seem to think it is. They still transact over SMTP...
Completely. In the corporate world, Microsoft is the dominant player, but on premise is still a thing, as are other ESPs. Gmail is nowhere near as dominant as people seem to think it is. They still transact over SMTP...
The last time I tried Codium, not being able to use Remote Development was a showstopper. Has the situation improved since then?
No, and don't expect it or Live Share to ever land[0].
None of the "Remote" extensions are FOSS, and they restrict usage to "validly licensed" copies of VS Code[1] – plus the server side code for it is closed source. So getting it into Codium would require a clean room implementation, essentially.
[0] https://github.com/VSCodium/vscodium/wiki/Extensions-Compati...]
[1] https://marketplace.visualstudio.com/items/ms-vscode-remote....
[0] https://github.com/VSCodium/vscodium/wiki/Extensions-Compati...]
[1] https://marketplace.visualstudio.com/items/ms-vscode-remote....
The extension API proposals and RPC protocol are open sourced and the server code is just an electron-less version of the regular VSCode extension host (hence, remote extension host, REH). This is all part of the VSCode OSS release.
What the proprietary extensions provide is integration. For example, the SSH variant automatically installs and launches an REH instance on the remote host and sets up port forwarding. If you are willing to start the instance and to forward ports yourself, you can use the tiny extension I wrote [1,2] (See the README how to enable the necessary extension proposals.). It allows you to connect to a local port you configure in the config. It is based on an example extension (vscode-test-resolver) in the OSS release that is used to test this functionality [3].
Microsoft is not really hiding any of this, so I am a little surprised, that nobody wrote a similar extension so far...
[1] https://open-vsx.org/extension/xaberus/remote-oss [2] https://github.com/xaberus/vscode-remote-oss [3] https://github.com/microsoft/vscode/tree/main/extensions/vsc...
Microsoft is not really hiding any of this, so I am a little surprised, that nobody wrote a similar extension so far...
[1] https://open-vsx.org/extension/xaberus/remote-oss [2] https://github.com/xaberus/vscode-remote-oss [3] https://github.com/microsoft/vscode/tree/main/extensions/vsc...
Nice work! The Remote Development license I linked earlier specifically excludes one from "reverse engineer[ing]" the code – which appears also to apply "to any Microsoft services... for the software".
IANAL, but I'd definitely be nervous to touch this stuff with a 10ft pole.
IANAL, but I'd definitely be nervous to touch this stuff with a 10ft pole.
> So getting it into Codium would require a clean room implementation, essentially
... if you want to go the legal route. ;-)
... if you want to go the legal route. ;-)
As a person who administers servers I absolutely HATE that vscode does this.
I don't know much about the specifics of remote deployment, but I feel like having vscode do this is just the wrong approach. I would say it probably needs to be some other CI/CD pipeline or something outside of the editor.
The problems I have is that every user gets like 1.5G of node junk stuffed in their home directory to support this. VScode spawns processes as the user that can't be controlled that can just kill servers (This is one bug I found, but there are issues with this that go much farther back than 2 years ago, https://github.com/microsoft/vscode-remote-release/issues/26...)
There doesn't seem to be any way to control this on the server side, so if I have users with the ability to write to their home directory, I cannot stop them from pushing this and potentially killing an instance.
I don't know much about the specifics of remote deployment, but I feel like having vscode do this is just the wrong approach. I would say it probably needs to be some other CI/CD pipeline or something outside of the editor.
The problems I have is that every user gets like 1.5G of node junk stuffed in their home directory to support this. VScode spawns processes as the user that can't be controlled that can just kill servers (This is one bug I found, but there are issues with this that go much farther back than 2 years ago, https://github.com/microsoft/vscode-remote-release/issues/26...)
There doesn't seem to be any way to control this on the server side, so if I have users with the ability to write to their home directory, I cannot stop them from pushing this and potentially killing an instance.
Luckily, contrary to what the Microsoft hoard will tell you, there are countless respectful alternatives that were around before and will be around long after Microsoft turns it into some kind of pay to win thing with achievements.
I want to believe this, but my experience with VSCode generally goes like this: I find a bug in a tool I rely on or want to make a PR with some feature I think could be generally useful. Turns out the tool uses a language I've not used before, or requires me to test for multiple platforms, or something. In any case I have to start from scratch. So I just lookup 'how to X in VSCode' and/or open VSCode, go to Extensions. Follow some simple instructions, get what's needed and a couple minutes later I'm developing. And fairly decent step-by-step debugging + watch windows and whatnot. And debugging remotely on another platform. And sometimes VS Code then also offered to install the complete toolset needed on that platform.
Now, maybe I've just been lucky, or toolsets just got better overall, or maybe I've missed something, but when I did this 20 years ago there was a good chance I was looking at a non-trivial amount of research, finding tools, fiddling with config files, text-based debugging at best sometimes or hideous IDEs, etc. So alternatives exist, one can call them respectful, but turns out for a couple of usecases that's besides the point: the experience for one-off 'let me just quickly try this in whatever is the cool language of the day' is, as far as I'm aware, simply unsurpassed. And that's the strength for me. Not sure if I'd be paying for that, but right now it's just what it is.
Now, maybe I've just been lucky, or toolsets just got better overall, or maybe I've missed something, but when I did this 20 years ago there was a good chance I was looking at a non-trivial amount of research, finding tools, fiddling with config files, text-based debugging at best sometimes or hideous IDEs, etc. So alternatives exist, one can call them respectful, but turns out for a couple of usecases that's besides the point: the experience for one-off 'let me just quickly try this in whatever is the cool language of the day' is, as far as I'm aware, simply unsurpassed. And that's the strength for me. Not sure if I'd be paying for that, but right now it's just what it is.
Nitpick: s/hoard/horde/g
Nitpick: g flag not necessary here ;)
Curious what the s in the front is for? Looks like regex but I've never seen this syntax specifically before.
Also: https://en.m.wikipedia.org/wiki/Muphry%27s_law
Also: https://en.m.wikipedia.org/wiki/Muphry%27s_law
Merci beaucoup
If you're really that concerned about using propriety software why not help build the emacs or vim ecosystem instead?
As someone who has been using vim for 5 years and neovim for 2 years, what sort of learning material (books, videos) would you recommend to learn about vim internals and subsequently neovim internals?
I would love to contribute but I'm mostly a webdev, but I'd love to take a year or so to learn and hopefully contribute throughout the rest of my life. It's just so hard to start or learn.
The material doesn't even have to be directly related to vim, I'd like to learn more about how and why text editors work and some of the common concerns when building one.
I would love to contribute but I'm mostly a webdev, but I'd love to take a year or so to learn and hopefully contribute throughout the rest of my life. It's just so hard to start or learn.
The material doesn't even have to be directly related to vim, I'd like to learn more about how and why text editors work and some of the common concerns when building one.
It will require you to venture into C land, but I found the walkthrough of the code for the kilo editor [0] to be very informative. It’ll hit on a number of the basic concerns that a console-based editor needs to solve. Any vi/emacs impl will obviously be a lot more complex, but a simpler starting point is better for learning.
[0] https://viewsourcecode.org/snaptoken/kilo/
[0] https://viewsourcecode.org/snaptoken/kilo/
Depends what you want to do.
The editor itself is in C; I don't think there's any "learning materials" available for the (Neo)Vim internals specifically, so you just gotta learn C. Overall, it's not that hard IMO: I'm not a very experienced C programmer, and I managed to get some patches into Vim. Neovim also uses Lua in various parts for its internals, but I'm not very familiar with Neovim.
If you want to work on things like language support (syntax files, some completions) then most of that is in VimScript; "Learn VimScript the hard way" is a good place to get started.
The editor itself is in C; I don't think there's any "learning materials" available for the (Neo)Vim internals specifically, so you just gotta learn C. Overall, it's not that hard IMO: I'm not a very experienced C programmer, and I managed to get some patches into Vim. Neovim also uses Lua in various parts for its internals, but I'm not very familiar with Neovim.
If you want to work on things like language support (syntax files, some completions) then most of that is in VimScript; "Learn VimScript the hard way" is a good place to get started.
I don't understand that reasoning.
Wouldn't an editor ecosystem based on Codium be as open-source as Emacs' and Vim's?
Are you referring to some difference in their specific licenses?
Wouldn't an editor ecosystem based on Codium be as open-source as Emacs' and Vim's?
Are you referring to some difference in their specific licenses?
My argument, based on this thread alone, would be that Codium will always be... held back by its roots in open core project, with some amazing features (like remote editing) or plugins being unavailable. Codium developers do not "own" their core platform (they can't really fork it without breaking plugins), and they don't have much (if any) say in the future direction of it.
Given that it's not unreasonable to think that VS Code is not really that open, and a more desirable outcome would be for developers to support more open alternatives.
Thanks for explaining that. I hadn't considered the moat effect caused by defaulting to a plugin store that allows closed-source packages.
That said, it sounds like people are maintaining an equivalent store for Codium [0], and are populating it with most of the packages found in Microsoft's repo. I'd think addresses most of the concerns about that particular form of moating.
> with some amazing features (like remote editing) or plugins being unavailable
The remote-editing package is definitely a sticking point for me. Is there some reason to believe that an open-source equivalent is out of reach?
I'm speaking from a place of ignorance on this, but I'd expect someone out there to want to do the work of writing that OSS package. Particularly if they preferred Codium over Vim/Emacs for other reasons.
That said, it sounds like people are maintaining an equivalent store for Codium [0], and are populating it with most of the packages found in Microsoft's repo. I'd think addresses most of the concerns about that particular form of moating.
> with some amazing features (like remote editing) or plugins being unavailable
The remote-editing package is definitely a sticking point for me. Is there some reason to believe that an open-source equivalent is out of reach?
I'm speaking from a place of ignorance on this, but I'd expect someone out there to want to do the work of writing that OSS package. Particularly if they preferred Codium over Vim/Emacs for other reasons.
It's almost like chromium versus firefox.
As another poster here, I would love to help contribute to emacs. What would I need to learn and where would I start?
Because some people don't necessarily want to tinker with emacs or vim for days just to get their perfect setup going
days? Surely, you jest, dear Sir. Proud emacs user for 21 years, still have to get some overlay function going just the way I like it. One of these days, I am going to get it just right.
Joking aside, I think that’s one of the great things about emacs: years will go by and i won’t touch my config. Then a new project or something will inspire me to get back into it. But since switching about a decade ago, i’ve never had the itch to move to a different “editor”
Convenience or freedom. Pick one.
> for days
Ha!
:wq
Ha!
:wq
I can partially understand the desire to switch if there are (free) plugins available on VS Codium that is not on VS Code. However leaving VS Code because of not trusting Microsoft's off switch for telemetry for the IDE and the plugins they provide is an unintentionally uninformed decision IMO.
Of all actors, one should probably trust the privacy protections and off switch of a BigCo, like Microsoft, since they tend to know what would get them in trouble. On the other hand, you may not be able to rely on the open source plugin developers to do things right and protect your privacy, however, it usually can be a problem that can be fixed [1]. Do you read the source code of all of your plugins? Open source developers may have good intentions, but they may not be following telemetry guidelines or best practices.
[1] https://news.ycombinator.com/item?id=31371979
Of all actors, one should probably trust the privacy protections and off switch of a BigCo, like Microsoft, since they tend to know what would get them in trouble. On the other hand, you may not be able to rely on the open source plugin developers to do things right and protect your privacy, however, it usually can be a problem that can be fixed [1]. Do you read the source code of all of your plugins? Open source developers may have good intentions, but they may not be following telemetry guidelines or best practices.
[1] https://news.ycombinator.com/item?id=31371979
The company that has been caught with its hand in the cookie jar…
I don't know, several hundred times?
I don't know, several hundred times?
The company that doesn't wash it's hands, has it's pants down, is regularly stuffing it's mouth with stolen cookies, doesn't even bother to take it's hand out of the jar when responding to allegations, but also for some reason has numerous shills claiming has done nothing wrong.
Awesome. Wouldn't have put it quite so creatively, yet not able to disagree either. :-D
I originally read it as a different editor entirely than VS Code.
The slight startup delay for VS Code vs. for example Notepad++ is quite annoying. I wish there was software as cool as VS Code, but with ultra low startup time.
The slight startup delay for VS Code vs. for example Notepad++ is quite annoying. I wish there was software as cool as VS Code, but with ultra low startup time.
Is this attributed to VS Code's use of Electron?
I'm curious if VS Code's design makes it practical to replace Electron with another framework. E.g., Qt, GTK, simpler HTML, or whatever's most idiomatic for Win64 GUIs these days.
I'm curious if VS Code's design makes it practical to replace Electron with another framework. E.g., Qt, GTK, simpler HTML, or whatever's most idiomatic for Win64 GUIs these days.
Neovim?
Putting a lot of faith in this: “These extensions are uploaded by the official developers or by the community.”
Alas without ssh remote that’s a complete non starter for me
I find sshfs more versatile. Works in vscodium and allows you to use native file browsers and other external tools on the same connection.
The reasons to switch don't make sense. Microsoft provides builds for virtually every major platform and has extensive remote development options. Why is there a requirement to be building it from source?
What is collected via telemetry is published, can be inspected with tools Microsoft provides or third party tools, and can be disabled.
Why are some extensions providing paid versions while keeping the free versions around a bad thing?
What is collected via telemetry is published, can be inspected with tools Microsoft provides or third party tools, and can be disabled.
Why are some extensions providing paid versions while keeping the free versions around a bad thing?
Vim users out here like:
“Telemetry? What telemetry?” ;)
“Telemetry? What telemetry?” ;)
You can use the VSCode extension gallery with VSCodium at your own risk[0].
[0] https://github.com/VSCodium/vscodium/blob/master/DOCS.md#how....
[0] https://github.com/VSCodium/vscodium/blob/master/DOCS.md#how....
> There is nothing wrong with an organization following an open-core princip[le].
In itself, maybe, but MS is crippling the ability to use the open core. Plus, there _is_ something wrong with using the state to prevent people from copying information amongst themselves.
> Microsoft still has to pay for the developers who contribute to VS Code and other bills associated with VS Code and running the extension store.
If that's the justification, then it's BS. Microsoft has enough money to pay for this stuff many time over. Plus, the indirect financial benefit of people working in an MS app or environment is high enough.
In itself, maybe, but MS is crippling the ability to use the open core. Plus, there _is_ something wrong with using the state to prevent people from copying information amongst themselves.
> Microsoft still has to pay for the developers who contribute to VS Code and other bills associated with VS Code and running the extension store.
If that's the justification, then it's BS. Microsoft has enough money to pay for this stuff many time over. Plus, the indirect financial benefit of people working in an MS app or environment is high enough.
Their main argument is “no telemetry” (or sometimes “no cemetery tracking”…), but VS Code has a setting to disable telemetry [0], and I would trust that it’s really disabled if you set it so (why would they lie about something quite trivial to check with Wireshark or such?)
> I’m sure there is a small performance gain because you don’t have telemetry running in the background sending data to Microsoft.
Have you profiled it? Have you compared VSCodium and VSCode with telemetry off?
[0]: https://code.visualstudio.com/docs/getstarted/telemetry
> I’m sure there is a small performance gain because you don’t have telemetry running in the background sending data to Microsoft.
Have you profiled it? Have you compared VSCodium and VSCode with telemetry off?
[0]: https://code.visualstudio.com/docs/getstarted/telemetry
I agree but also - a controversial opinion - I am pretty sure Microsoft collects the kind of telemetry to learn about user behavior and improve the IDE, and not to collect private information for some kind of other gain. I am sure that whoever develops Codium will eventually get into a dead-end at some point because they won't have any telemetry connected to the product usage. Other piece is that Codium might inherently actually thrive because of some product decisions based on the telemetry Microsoft has so so it's not a fair fight.
Disclaimer: I am a Microsoft employee and this is my opinion only but I say this because I know what it's like to work on apps used by tens of millions of people and I can tell you that you're dead in the water when you have no idea how people use your product. And no, at this scale, controlled user testing is not sufficient. I've worked on countless Microsoft products over the years from Office through Skype to Teams. I've also been personally adding some telemetry into these but ALWAYS to be data driven when making product decisions such as "which button should we display here", "did we improve latency/stability/discoverability/.." and "which new feature will be actually useful".
Now.. I don't know VS Code 100% but I did see some internal talks, have access to some telemetry (didn't browse it much) and I can say that the team is full of good intentions. They just deal with difficult UX problems. I've also worked at Google and I think it's much different when your product/business is using/selling data about customers as compared to creating tools for developers. You are after a very different type of data in essence and I think the actual privacy is not contended here.
I am sure people will spin this the usual way "big company big bad" and "you never know what they will try to collect next" but in that case, I can only suggest you get a job in one of these companies and see how you will develop anything without real data to back your decisions and assumptions about the real world.
Disclaimer: I am a Microsoft employee and this is my opinion only but I say this because I know what it's like to work on apps used by tens of millions of people and I can tell you that you're dead in the water when you have no idea how people use your product. And no, at this scale, controlled user testing is not sufficient. I've worked on countless Microsoft products over the years from Office through Skype to Teams. I've also been personally adding some telemetry into these but ALWAYS to be data driven when making product decisions such as "which button should we display here", "did we improve latency/stability/discoverability/.." and "which new feature will be actually useful".
Now.. I don't know VS Code 100% but I did see some internal talks, have access to some telemetry (didn't browse it much) and I can say that the team is full of good intentions. They just deal with difficult UX problems. I've also worked at Google and I think it's much different when your product/business is using/selling data about customers as compared to creating tools for developers. You are after a very different type of data in essence and I think the actual privacy is not contended here.
I am sure people will spin this the usual way "big company big bad" and "you never know what they will try to collect next" but in that case, I can only suggest you get a job in one of these companies and see how you will develop anything without real data to back your decisions and assumptions about the real world.
> I am sure that whoever develops Codium will eventually get into a dead-end at some point because they won't have any telemetry connected to the product usage.
Note that VSCodium is not a fork; it's just a build of the open-source VSCode parts with telemetry patched out and a few other minor changes.
Note that VSCodium is not a fork; it's just a build of the open-source VSCode parts with telemetry patched out and a few other minor changes.
I am really curious but do not have the time to check this myself: is the vscode telemetry part of the open core bit? The reason I ask this is because I agree with your points and I usually allow telemetry for FOSS programs (for example [1]).
If the telemetry code is open and people can verify that there isn't any identifiable data that is being collected, I don't see any issue with leaving it on in vscode too.
[1] https://blog.davidedmundson.co.uk/blog/what-we-can-learn-fro...
If the telemetry code is open and people can verify that there isn't any identifiable data that is being collected, I don't see any issue with leaving it on in vscode too.
[1] https://blog.davidedmundson.co.uk/blog/what-we-can-learn-fro...
Some of the telemetry is not added until when later when VSCode get bundled with it and some proprietary stuff and signed for distribution. This is where VSCodium do the stuff. they take the same source code, apply some patches and build the program with open-vsx open source marketplace and they call it a day.
All of this actually happens and piped using github action found on the repository. You can have a look there.
All of this actually happens and piped using github action found on the repository. You can have a look there.
Is the telemetry data in KDE publicly available?
This doesn't jibe with history. Or the present for that matter, see sibiling to your comment by btdmaster. Uses of data always expand, never contract.
It doesn't matter that most or even 99% of the data is harmless, or that the data is useful, these companies are simply not trustworthy. The fact that no one asks permission up front (opt-in) tells you all you need to know.
It doesn't matter that most or even 99% of the data is harmless, or that the data is useful, these companies are simply not trustworthy. The fact that no one asks permission up front (opt-in) tells you all you need to know.
Shameless plug: I would love your "good words/faith" about me so I could get hired by Microsoft :P
VS Codium has tried, and not succeeded, to disable all telemetry[0][1]. This is with direct access to and patches to source code and all the knobs set to off.
If the direction of upstream is diametrically opposed to downstream, it is nearly impossible to prevent these issues.
[0] https://github.com/VSCodium/vscodium/issues/623
[1] https://github.com/VSCodium/vscodium/issues/631
If the direction of upstream is diametrically opposed to downstream, it is nearly impossible to prevent these issues.
[0] https://github.com/VSCodium/vscodium/issues/623
[1] https://github.com/VSCodium/vscodium/issues/631
Neither of those issues describe any telemetry, unless you define "telemetry" as "uses any internet connectivity that's not even to Microsoft's servers".
Is the default npm registry not operated by Microsoft? GitHub definitely is, and that was one of the pings.
It's probably some feature; "runs npm when I navigate its sources (js and ts files)" almost certainly is.
There are basically no details at all other than "I saw it did something with the network, therefore telemetry!"
There are basically no details at all other than "I saw it did something with the network, therefore telemetry!"
The open-vsx.org loads Google Analytics (via GTM) for telemetry, without any prompts or consent, with no way to opt out of it AFAICT.
If Windows, Office, LinkedIn, GitHub, Skype and Chat are any indication, the telemetry situation will worsen severely over time.
[deleted]
> f [sic] you want to get the full open-source MIT-licensed VS Code with no cemetery [sic] tracking
I prevent telemetry tracking by blocking all network access to VSC using Little Snitch. Get it set up initially with plugins then cut it off. I don’t use VSC in ways that require network access thereafter.
I prevent telemetry tracking by blocking all network access to VSC using Little Snitch. Get it set up initially with plugins then cut it off. I don’t use VSC in ways that require network access thereafter.
> I don't mean to offend any VSC fans out there but the Jetbrains IDEs are simply better and more mature in every single way.
I must admit that I used PyCharm for a few years but ended up liking VSC more, and now that's my IDE. Just seems lighter and more pleasant.
I must admit that I used PyCharm for a few years but ended up liking VSC more, and now that's my IDE. Just seems lighter and more pleasant.
I tried VS Codium early this year and went back to VS Code as clangd extension didn't work. Microsoft's C++ extension works great. I'll be interested to know if anyone has got clangd setup working on Windows.
lot's of MS extensions are missing but you often find OSS alternatives. Most important for me is liveshare. I use codetogether.com, it's not remarkable (I got connection drop a couple of times) but it does the job with the added bonus that it works with IntelliJ too
> with no cemetery tracking
FYI, if the author is here, I think you may have meant “telemetry” instead of “cemetery”.
FYI, if the author is here, I think you may have meant “telemetry” instead of “cemetery”.
(Proprietary is spelled propriety in a few places.)
I’m surprised VS Codium is so well packaged..
I’m surprised VS Codium is so well packaged..
And principle is spelled principal in one place.
I wonder if
I wonder if
principle/principal
border/boarder
could have/could of
their/they're
its/it's
The whole article is full of typos and misspellings. Doesn't appear to be particularly insightful either...
Did it two weeks ago.
This is actually great news. Some extensions, especially language ones, are very poor, and paying for them (if someone makes a commercial version) is the only way to guarantee a good development experience. Ruby is an example, and switching to IntelliJ is not smooth for people used to VSC.