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".
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.
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.
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.
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.
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.
> 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...
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.
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.
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!
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.
> 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.
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.
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.
Developers also have to put food on the table. 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.
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.
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.
- 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...".
Yet most employers who can afford to pay developers their high salaries are rent seekers. That’s hypocrisy right there.
So by your definition, a stable salary writing software is a form of “rent seeking” in open source, but totally acceptable as a job?
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.