WebStorm and Rider Are Now Free for Non-Commercial Use(blog.jetbrains.com)
blog.jetbrains.com
WebStorm and Rider Are Now Free for Non-Commercial Use
https://blog.jetbrains.com/blog/2024/10/24/webstorm-and-rider-are-now-free-for-non-commercial-use/
63 comments
> My JetBrains all products pack is one of the few subscriptions
I happily pay this every year myself, but I think it's important to note it's not really a subscription. You pay for software, and you keep that software forever. If you stop paying, you still get to keep what you paid for. What you pay for every year are the updates.
I know it's a subtle distinction, but I think it's an important one to make. Again, I happily pay every where, and it acts very much like a subscription, but it's not like a Creative Suite subscription. If you stop paying, you an always just stay on the software you paid for.
I happily pay this every year myself, but I think it's important to note it's not really a subscription. You pay for software, and you keep that software forever. If you stop paying, you still get to keep what you paid for. What you pay for every year are the updates.
I know it's a subtle distinction, but I think it's an important one to make. Again, I happily pay every where, and it acts very much like a subscription, but it's not like a Creative Suite subscription. If you stop paying, you an always just stay on the software you paid for.
OMG, I stopped paying for DataGrip and Rider about six months ago and still have full access to them on my work PC for daily use. My personal Mac, though, immediately flagged the expired license once it was up. I actually thought it was some kind of bug on my work setup that let me keep using Rider, DataGrip, and IntelliJ, but I guess it’s just how it’s designed to work if you stay on the last paid version?
iirc only if you have paid for a continuous year.
Jetbrains does do one thing slightly differently from most "subscription to own" things. You’re only entitled to the version that was current when you last paid your bill. Depending on your billing cycle, this could be the latest one you were using, or it could be up to 1 year old.
It’s a bit odd. I wish I was paying for 1 year of updates.
It’s a bit odd. I wish I was paying for 1 year of updates.
I'm all in with the JetBrains love, but for clarity, you can keep the first version you paid for indefinitely not the last. So if you decide to stop paying the subscription you have to go back to a year old version.
Right, the version that was active when you last paid the bill.
I've been paying for the subscription for years, so "first" isn't quite right either, because for me that would be some very old version.
I've been paying for the subscription for years, so "first" isn't quite right either, because for me that would be some very old version.
Same here, I imagine also how had is for them to compete against free products paid by tech giants, they have no choice then be better and threat the users with respect.
Same here. The JetBrains products are indispensable for me. They've converted me after being an Emacs user for 30 years.
Can you imagine if JetBrains worked their magic on Emacs?!
Years ago, there was a company that made a refactoring engine for C, I believe I paid >100$ for it in the late 90s or early 2000s. It was a standalone server that could communicate with Emacs (I wasn't an Emacs user). For a consulting engagement, I bought this tool and learned Emacs. I printed out a poster that I put on the wall that show the workflow for the most common tasks I needed to accomplish. I could not have completed it without it.
I discussed this with other programmers at the time, and they were somewhat incredulous that I bought software instead of spending 10x the time to complete the task. Knowing when to buy tools is a skill in and of itself.
Years ago, there was a company that made a refactoring engine for C, I believe I paid >100$ for it in the late 90s or early 2000s. It was a standalone server that could communicate with Emacs (I wasn't an Emacs user). For a consulting engagement, I bought this tool and learned Emacs. I printed out a poster that I put on the wall that show the workflow for the most common tasks I needed to accomplish. I could not have completed it without it.
I discussed this with other programmers at the time, and they were somewhat incredulous that I bought software instead of spending 10x the time to complete the task. Knowing when to buy tools is a skill in and of itself.
> Can you imagine if JetBrains worked their magic on Emacs?!
No need for a mouse and on-the-fly macro recording and replaying? How many first-born do they want?
No need for a mouse and on-the-fly macro recording and replaying? How many first-born do they want?
Specifically worth noting:
> It’s important to note that, if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics.
> It’s important to note that, if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics.
This is a common and acceptable tradeoff for free products.
https://intellij-support.jetbrains.com/hc/en-us/community/po...
not just anonymous statistics, i presume
not just anonymous statistics, i presume
> Earlier this year, we implemented a new licensing model for our recently introduced IDEs, RustRover and Aqua, making them free for non-commercial use. We’re now extending this model to WebStorm and Rider. If you’re using these IDEs for non-commercial purposes, such as learning, open-source project development, content creation, or hobby development, you can now do so for free.
However, be careful with the terms of non-commercial usage (Enforced heavy metrics)
"You agree that the product will send usage data to validate your compliance with the license terms and anonymous feature usage statistics..."
"The information collected under Sections 4.1. and 4.2. may include but is not limited to frameworks, file templates used in the Product, actions invoked, and other interactions with the Product’s features."
"You agree that the product will send usage data to validate your compliance with the license terms and anonymous feature usage statistics..."
"The information collected under Sections 4.1. and 4.2. may include but is not limited to frameworks, file templates used in the Product, actions invoked, and other interactions with the Product’s features."
Huge! Forced data collection, I hope at least the code is not sent for training
As mentioned in the blog post, the statistics include IDE-related data, such as user actions, and basic information about the project, including frameworks and libraries (though limited to a predefined whitelist). Overall, this is quite similar to the data collection done by EAP for the products.
Source code is never sent under any circumstances.
Source code is never sent under any circumstances.
There is enough of code on the internet already for big tech to train , what is probably missing is some scoring or labeling for that code so this AIs stop suggesting outdated stuff or bad stuff.
JetBrains fanboys won't understand or acknowledge that the free versions of JetBrains IDEs are just not competitive anymore against VSCode. This is for multiple reasons. For example, these features are present in VSCode for free, but not in JetBrains IDEs:
(1) CoPilot code completion (for open source GitHub users)
(2) devcontainer integration
(3) docker integration
(1) CoPilot code completion (for open source GitHub users)
(2) devcontainer integration
(3) docker integration
As a person that frequently uses vscode and the paid versions of the jetbrains IDEs: Aren't these just Plugins you can install from the settings(both for vscode and jetbrains IDEs)?
Do the free versions not include plugin support?
Do the free versions not include plugin support?
The GitHub Copilot integration is built by Microsoft and is present in both of the CE builds (IntelliJ and PyCharm). I'm not at all sure why they think it's not.
OP is correct about Docker integration and Dev Containers: they cannot be added to the free versions. Dev Containers specifically seems to be OP's big sticking point, but it's a weirdly pedantic point. JetBrains can't give everything away for free or they wouldn't be able to fund their development.
Picking a few professional-grade features and asking people to pay if they really need them is a totally reasonable approach.
OP is correct about Docker integration and Dev Containers: they cannot be added to the free versions. Dev Containers specifically seems to be OP's big sticking point, but it's a weirdly pedantic point. JetBrains can't give everything away for free or they wouldn't be able to fund their development.
Picking a few professional-grade features and asking people to pay if they really need them is a totally reasonable approach.
> The GitHub Copilot integration is built by Microsoft and is present in both of the CE builds (IntelliJ and PyCharm).
Apologies. Nevertheless, going by its user reviews, it gets the short end of the stick relative to what's in VSCode. Those who've used it with both PyCharm and VSCode seem to prefer using it in VSCode because they find various functionalities lacking in PyCharm.
Apologies. Nevertheless, going by its user reviews, it gets the short end of the stick relative to what's in VSCode. Those who've used it with both PyCharm and VSCode seem to prefer using it in VSCode because they find various functionalities lacking in PyCharm.
[deleted]
Like I said already, the free versions of JetBrains IDEs do not have these plugins or features.
They are very competitive unless you program in a shitty language like JS. 1 is no different. And the other two are simply useless to me for any kind of development (and yes, I do fullstack, just not with Node).
> JetBrains fanboys won't understand or acknowledge that…
If a tool works for them, then it works. I don’t think that’s a lack of understanding on their part.
If the opposing view is « clearly VSCode is objectively the only choice », then I think that camp has a distinct lack of understanding that people’s needs are diverse and no 1 tool solves every problem for all people.
If a tool works for them, then it works. I don’t think that’s a lack of understanding on their part.
If the opposing view is « clearly VSCode is objectively the only choice », then I think that camp has a distinct lack of understanding that people’s needs are diverse and no 1 tool solves every problem for all people.
I am not opposed to the paid versions of JetBrains IDEs. I think it's a great offering. I am just saying that the free versions of JetBrains IDEs are not competitive with VSCode. JetBrains has intentionally withheld the plugins. JetBrains also has a bad habit of introducing free plugins, but then taking them away. The features I noted are major modern features that not all older developers have come to appreciate yet.
I think it’s just how you’re framing it. It sounds like you’re saying that people using Jetbrains free IDEs are somehow just missing some objective truth you are aware of.
If someone prefers Pycharm CE, it’s quite condescending to say « they just don’t understand ». Different strokes for different folks?
If someone prefers Pycharm CE, it’s quite condescending to say « they just don’t understand ». Different strokes for different folks?
Nope. Using PyCharm CE without container integration is like driving without seatbelts; it's a substantial security hazard because there is no filesystem isolation whatsoever with PyCharm CE. You get that for free in VSCode. Now if you still argue that seatbelts aren't for everyone, then you are living in the past.
[deleted]
JetBrains IDEs are better than VSCode, but due to Copilot integration in VSCode, I moved away from JetBrains. I don't see myself going back to JetBrains.
Secondly, the free JetBrains IDEs also lack devcontainer support which is readily present in VSCode. To not use devcontainer is a substantial security hazard.
Secondly, the free JetBrains IDEs also lack devcontainer support which is readily present in VSCode. To not use devcontainer is a substantial security hazard.
>Secondly, the free JetBrains IDEs also lack devcontainer support
Actually, there is a significant difference between the community versions (e.g. for PyCharm) and the versions available for non-commercial use. The latter are full versions of the products without any reduced functionality, whereas the community editions have certain features trimmed.
Actually, there is a significant difference between the community versions (e.g. for PyCharm) and the versions available for non-commercial use. The latter are full versions of the products without any reduced functionality, whereas the community editions have certain features trimmed.
JetBrains simply is uncompetitive. It doesn't make sense to have to pay for an important feature (container integration via devcontainer or docker) that is already free in a competing IDE (VSCode).
>Secondly, the free JetBrains IDEs also lack devcontainer support which is readily present in VSCode. To not use devcontainer is a substantial security hazard.
Can you elaborate? Is VS Code making containers for you so you are safe from packages or from random plugins you have to install?
Can you elaborate? Is VS Code making containers for you so you are safe from packages or from random plugins you have to install?
Why do I have to elaborate? It is well known that a container offers a sandbox and process isolation. The risk from not using one can be severe. The risks include but are not limited to packages and plugins.
> Why do I have to elaborate?
Because some of us have never heard of devcontainers as a named concept with its own spec until now. I've been running my dev servers inside containers for a long time now (using JetBrains IDEs!), but have never heard of this before.
> It is well known that a container offers a sandbox and process isolation.
No, actually, it's well known that containers don't do that. It's one of the first things you learn when you start learning about containers—they are not virtual machines and are not suitable for running untrusted code, because they share a kernel with the host.
I just read through the introduction to devcontainers and there are lots of benefits it discusses but security isn't one of them:
https://containers.dev/
Because some of us have never heard of devcontainers as a named concept with its own spec until now. I've been running my dev servers inside containers for a long time now (using JetBrains IDEs!), but have never heard of this before.
> It is well known that a container offers a sandbox and process isolation.
No, actually, it's well known that containers don't do that. It's one of the first things you learn when you start learning about containers—they are not virtual machines and are not suitable for running untrusted code, because they share a kernel with the host.
I just read through the introduction to devcontainers and there are lots of benefits it discusses but security isn't one of them:
https://containers.dev/
> security isn't one of them
Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.
Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.
>Oh but it is. If there is harmful data-stealing software running in the container, it will remain isolated to the container. And if the kernel is shared with the host, that's a read-only share.
And what protects the production server when you deploy the evil packages?
And what protects the production server when you deploy the evil packages?
> remain isolated to the container.
Assuming the code that implements the containerization is 100% bug free and there are no container escapes. I would not bet my user's safety purely on that assumption.
Assuming the code that implements the containerization is 100% bug free and there are no container escapes. I would not bet my user's safety purely on that assumption.
This is as useful as saying that seat belts do not make you safer because people still die in crashes. Containers are not perfect but if you’re starting from the conventional position where you’re one wrong package install away from an attacker having arbitrary access to your account and data, they’re a significant immediate improvement and a good foundation for further improvement.
Yes, exactly. JetBrains fanboys will prefer to remain blind to it, however, not realizing that the free version of JetBrains isn't competitive anymore against VSCode.
People pay for JetBrains instead of the free VS Code, and there are reasons for that, like IDE features and quality. Anyway there is no need to start an IDE war here, use whatever works for you and your coding, but I am sure that a small company can't offer free stuff and survive like big tech can do, so as a paying customer I want them to survive and make good products rather to give free shit to people that don't want to pay for their tools.
VSCode has raised the bar of what to expect from a free IDE in terms of container integrations. JetBrains has fallen behind, and is sticking to a decade old standards.
I have no problem with the paid versions of JetBrains IDEs which I think are great, but to pay, one has to first find value in the free version (which is now lacking).
I have no problem with the paid versions of JetBrains IDEs which I think are great, but to pay, one has to first find value in the free version (which is now lacking).
I think you're missing my point: you are saying that it is one of the benefits, but they don't because it isn't one. Containers are not a security solution for running untrusted code. You saying they are does not make it so.
> And if the kernel is shared with the host, that's a read-only share.
No, it's not, the kernel is reading and writing files constantly for the container. A bug in the kernel could be exploited to break the sandbox, which isn't possible in a true VM.
> And if the kernel is shared with the host, that's a read-only share.
No, it's not, the kernel is reading and writing files constantly for the container. A bug in the kernel could be exploited to break the sandbox, which isn't possible in a true VM.
There is no such thing as perfect security. Partial security is much better than none at all. Containers go a long way in this regard. All code is untrusted.
> Partial security is much better than none at all.
Only if you don't let down your guard because it's "secure". Again, there's a reason why they don't claim it's secure and everyone says to not treat containers as a sandbox.
Only if you don't let down your guard because it's "secure". Again, there's a reason why they don't claim it's secure and everyone says to not treat containers as a sandbox.
> Why do I have to elaborate?
It's well known that the comments on HN are great for having discussions. You don't have to participate, despite your belief that you are required to. But, it's well known that having a discussion is a two way street, with people commenting and asking questions, and people replying.
It's well known that the comments on HN are great for having discussions. You don't have to participate, despite your belief that you are required to. But, it's well known that having a discussion is a two way street, with people commenting and asking questions, and people replying.
So you are afraid of evil packages but then you deploy them in production? So you are safe and screw your users ?
Here’s a scenario: my development pipeline scans every package in the build but I can’t reach into a developer’s local shell session to prevent them from making a typo. Using a dev container changes that from “the attacker gets their data, keys, and anything their session credentials can access” to a more limited exposure and gives your other safeguards a chance to catch it.
So you force your devs to use your favortie IDE rhater then the best one? why not force them to use soem better stuff for this security purpose like virtual machines, docker , something that would be usefull for them to have experience with
This does use Docker - it’s literally just working in a container so it’s both useful experience and overlaps with your deployments so you avoid multiple layers of waste from VMs: everything is reproducible, people don’t hit problems due to untracked local state, and they don’t spend time on sysadmin work which isn’t directly related to what you deploy.
I used to think containers were they way and maybe they are, but so far my experiences with them has been really poor and marked by confusing interfaces and unnecessary GUI ops vs e.g. git ops.
If someone could explain to me how to programmatically perform all lifecycle features with a container (e.g. rebuild etc) without ever having to touch VSC’s special in-IDE command palette that would be incredible.
The current iteration is too much magic at the expense of too little control and visibility.
If someone could explain to me how to programmatically perform all lifecycle features with a container (e.g. rebuild etc) without ever having to touch VSC’s special in-IDE command palette that would be incredible.
The current iteration is too much magic at the expense of too little control and visibility.
And, of course, the other reason why I'm so enthusiastic about their products is that they're one of the only companies that has been able to maintain a thoroughly symbiotic relationship with the developer community. They somehow have consistently maintained a healthy balance of giving things away without losing their business—their subscription model is humane (you get to use the last version you paid for indefinitely), they have an open source core, and they lean in more than most to giving their paid products away to students and others who can't pay.