Yes, we need more tools that are cit friendly. If you are looking for a good GUI based client that works on top of plain text files, do checkout Bruno.
Popular app takes VC money and starts charging users for previously-free features once the pressure is on to earn returns. Users – who have been freeloading for years – can easily move to something else (or write their own version), but would rather just moan about it online.
This same scenario has played out 10000x with the exact same outcome, yet people keep expecting something different from the next one.
What is the right way to fund these kinds of tools?
Right now, it seems like it only happens a few ways:
- be a giant saas and use your "free for personal use" tier as a loss-lead/way to get devs using you, thus wanting to use you at work, then you charge their work. e.g. github.
- be linux and be a big enough critical piece to where companies actually fund you directly
- pay software engineers oodles of money so that they can have leisure time to maintain the plethora of random FOSS software that's out there
- leech off the social safety nets of other countries and let engineers subsisting off ramen in the netherlands write your foss software
- play the donation-to-COL arbitrage game and write FOSS from a third-world country where a meager stream of USD donations/purchases can sustain you reliably
Pretty much every single one of these except the linux one is pretty awful. And we can't all be Linux. The second least problematic is probably the one where you pay engineers shittons of money and then let them do shit as side projects, but it seems really indirect.
> be a giant saas and use your "free for personal use" tier as a loss-lead/way to get devs using you, thus wanting to use you at work, then you charge their work. e.g. github.
Is not a bad option. Devs won’t pay for tools, but their orgs will. Isn’t that how it should be? My plumber’s employer pays for their Rigid $2k hydraulic copper fitting crimper, for example, because it saves time vs sweating pipes (enabling them to do more jobs, and generate more revenue).
Be the hydraulic crimper of dev tools. Expensive, but generating so much value no one batts an eye at paying for it (obligatory patio11 “you’re not charging enough” reference here). Some people will cheap out and pay $100 for the hand crimper and do their crimping by hand; don’t sell to them, they are not evaluating their time value efficiently (or they simply don’t need your tool).
For a recent example of this: Docker, going from $12M to $100M ARR within a year as soon as they started charging enterprise users.
Postman seems to be moving towards not aiming at developers as their main audience. Instead it's for QA, support, managers who want to make some queries against the internal API but can't use curl to do so.
It's an alternative, and as stated is my favorite. If closed source bothers you, find another alternative. Or you could continue to reply insufferably. The choice is yours.
What do you mean partially closed source? I thought Insomnia was fully open source[1] and I couldn't find any closed source elements after looking around.
I dont understand the sentiment behind these kinds of comments. They listed an alternative. Since when did alternatives mean open source only? I dont see it mentioned in HN guidelines either. And why is closed source considered to be bad by default? I have no idea.
There are wonderful closed source apps out there that are reliable and have been well maintained and never had any issues and nefarious open-source apps that did bait and switch, pulled off out of spite, shut down because of lack of funds and many more reasons.
We dont have to be snarky every time someone tries to suggest or do something. We could do better by listing may be a favorable alternative.
We are insulting both the developer and the commenter by being snarky.
What bothers me about Postman is how they took ownership of the popular httpbin project 5 years ago and left it to bitrot. They haven't made a single commit since then, not even dependency upgrades. Now it has acquired 5 years' worth of CVEs in its dependency chain. They receive PRs to fix those issues, but all PRs and issues are ignored.
Why take ownership of the project if when there's no intention of maintaining it from the very beginning? It's almost as if projects like httpbin are detrimental to their business.
Shameless plug: why not switch to Hurl [1], an open source cli tool to run and test HTTP requests in plain text, with libcurl under the hood? (I'm one of the maintainer)
Good things never last. I suppose it's time to start beefing up those collection exporters to the multiple freeware tools that do the exact same thing as postman.
I just used Postman yesterday for the first time in ages and loved how it had all my previous work saved in the cloud and restored it after logging in. Also, the pre-request script feature was great for calculating a signature of the request which had to be included in the request. Do other API clients have the scripting features of Postman?
Ease and iteration speed for complicated APIs. Why make notebooks when you can just make a single python script?
Well, same way that notebooks are a REPL that remembers things, it's helpful to rapidly tweak parameters in your API calls, flick a menu to point to a different environment, retry requests on your own local instance, etc. Then when you have it all ready, you just save and it's shared with your team, and the non-developers don't even need to learn what a virtualenv is. Even your CI can take advantage of it. Well, it could.
There's "nothing" Postman provides that you can't do with a python script and git, but it lets you move much faster and have a tighter iteration loop.
That said, paying $10/user/mo just to effectively share a bunch of json definitions was always a plan that only made sense with corporate credit cards. With this added artificial restriction, my team is going to be looking for other alternatives.
Dropbox gave a similar degree of convenience and that's why they took off. But once every cloud provider figured out they too can sync files in the cloud, the novelty became a commodity. This plan reeks of Postman being out of actual feature ideas so in their desperation they're just milking whatever they can get out of their corporates through artificial restrictions before "a cloud-sync'd API runner" becomes a software commodity and the lights go out.
That’s not a great comparison: the two tools have very different users, and if you’ve ever used Postman for anything non-trivial you’ve probably hit things which are but should not be substantial points of friction (secrets, OAuth renewal, diagnostic output, etc.) whereas Dropbox really did a great job of doing exactly what you wanted with a minimum of fuss.
Well and that's it right? They get developers on board early, and techies, etc... then shift to mass market and remove features and add anti-features.
Github, slack, whatever else. it's a big long cycle. Now I see tools like Postman and the first thing I think is "how do they want my money, whats their strategy financially", things I never thought when I bought a CD-ROM or a one-time license to tools.
I haven't touched Postman since they started pushing me to log in, but for me it was just an alternative to hitting GET endpoints with my web browser or piping curl to jq. If I'm looking through an API's docs and figuring out how it works, I often want to quickly test endpoints and see what they return. I could've written a script to do it, but Postman made that slightly easier by removing the need to write code or remember syntax.
postman gives you a lot "for free" in terms of development and you can ship your project around to other, less technical people, or to prospects as a sales tool. lower barrier to entry.
this is a dumb change, especially given you're not using any of their resources so artificial constraints on the number of runs makes zero sense.
It uses these amazing things called files. With files you can commit them to a repository of other files where your team can find them.
https://marketplace.visualstudio.com/items?itemName=humao.re...