I have few questions if you don't mind: Have you also made the project private? In other words, do you intend to develop it by yourself only or will it stay open to the community? How the development process is gonna look like? I know that there hasn't been much activity from the community recently however I didn't forget about the project and planned to continue with contributions when free time is available. I respect your decision and understand it to some degree. That being said, I feel like it's gonna prevent the community to grow or even to contribute (if we don't think about backport bugfixes). if I may ask, what's your intentions/thoughts? Thanks @eliangcs
@fogine I just generated and emailed you the access key. Let me know if it doesn't work.
Thank you very much for your concern. The project is still open source (but is now licensed under AGPL). What I'm doing is an "early access" business model. The open source branch (currently v0.9.3) is publicly available on GitHub. People still can participate in the project. The latest release (currently v0.10.0) is kept private until we have a newer release, say v0.11.0. I'll be the one who merges two branches, so that bugfixes and updates in the public branch are properly moved to the private branch and the other way around. Does it answer your question?
v0.10.x or a major version x.0.0 get released? Thanks.
@fogine yes, your presumptions are correct. So if a developer wants to extend swagger feature, he has to wait for the private branch to be published. The point of releasing a free version to the public is that I want to keep the free users. And people still can do minor changes like bugfixing. I guess this is a trade-off between the OSS community and commercialization.
Basically, the shifting point is based on whether we have any new features. If I added a new feature, the minor version goes up (such as v0.9.x -> v0.10.0), then the new version will be kept in private. If it just a bugfix or minor change, only the patch version increase (such as v0.9.2 -> v0.9.3), then we don't shift at all, i.e., private is still private, public is still public. However, I may move bugfix from private to public and vice versa. The same rule applies when we have a major version, say v1.0.x. It'll be kept in private first until we have v1.1.0. Regardless, I'm exploring with this early access idea and wanting to find out how it would work.
@eliangcs, The following is my view and thoughts.
By "a free community" expression I mean a group of people activelly interested in a project by participating in the development (with no expectation of financial profit) with anything more than small bug fixes or feature requests.
Personally, I don't think that the current business model is gonna work well with any kind of "free" community as contributors are basically cut off of upstream.
In my opinion, trying to get a free community work with commercialized sector is understandably only gonna get people confused. As you suggested, making a commercialized organization from the product could possibly work.
However, questions raise, whether the product is large enough? Can it produce enough value over time to sustain itself on the market and uphold its price demands?
Maybe it could make the organization more successful if the organization produced other related products along http-prompt...? Have you stumbled upon the Restlet company, @eliangcs?
I see two general approaches which tend to collide when combined.
- Free OSS community where options for any financial profits are limited and not guaranteed (bounties & support via patreon etc)...
Contributors are left to make ends meet aside their work in the OSS or count on voluntary financial supporters. This is the main reason why the OSS development tends to be noticeably slower then commercialized sector as free time of individuals is limited.
The main advantage is that literally everyone (without an exeption) can profit from produced value and everyone is welcomed in the community and has an opportunity to participate in final product. - In comercialized organizations (to any degree), members can afford to spend more time making the final product given a period of time.
Thus the organization produces more value over time (not necessarily of better quality ).
Drawbacks are that the right to profit from produced value (use product) is strictly conditional... it creates user expectation of the organization to produce value.
We can say that to certain degree we splitted OSS community to two groups, a group which produces value and the other one which uses the product.
I'm not even sure if the two approaches can be combined in today's society. I think the roots of the issue are in politics but let's not dive into that.
To answer your question more dirrectly, the current circumstances make me to reprioritize my current and future focus of my contributions in OSS
However it does not preclude me from contributing to http-prompt project as it will depend on how I will be using http-prompt, how much free time will be available and whether I will need some functionality not implemented yet.
if you were interested in more close collaboration, I'd be open to that.
I realize that I've written a lot of stuff you already know but still I hope these insights will be somewhat helpful to you.
@fogine thanks for the feedback! It's really valuable. I agree with you that current business model probably won't work and it retrains the community from growing. So I think I'll change my direction here. Instead of monetizing the core product (http-prompt), we should make another related product based on http-prompt. The related product is probably an SaaS that bring more organization-specific features to http-prompt, similar to what Postman and Insomnia do. Anyway, it's still undecided. In the short term, I would do the following:
- Remove the early access subscription
- Change http-prompt license back to MIT
- Release v0.10.0 publicly
Let me know if you have any other ideas. Thanks!
Hello all. Just found about this command line client. Is there a way to store/list/add/remove/manage a list of presets? Similar somehow to what you can do in Postman. What I mean is something like editing an input file in some format where you can list all your preset REST calls with their own properties. E.g.:
presets: [{
name: 'Load foos - Local machine',
url: 'http://localhost:1234/api/foo',
verb: 'get',
authorization: {
type: 'basic',
username: 'johndoe',
password: 'SECRET PASSWORD',
},
headers: [{
key: 'accept',
value: 'application/json',
}],
}, {
...
}],and then be able to feed one of this presets into http prompt command line: http-prompt --input ./my-presets.conf --preset 'Load foos - Local machine'
env command does. You can export the env output to a file. Then import it with exec or source command. Refer to the doc here: http://docs.http-prompt.com/en/latest/user-guide.html#saving-and-loading-sessions
file.json content
{
"addr0": "Unit 315, 3/f PAK TIN ESTATE, BLOCK 10, Shek Kip Mei",
"reference": "1",
"returnRecords": 10
}
when I run with debug mode , the content is
"data": "{\"field\": \"{\r\n\t\\"addr0\\": \\"Unit 315, 3/f PAK TIN ESTATE, BLOCK 10, Shek Kip Mei\\",\r\n\t\\"reference\\": \\"1\\",\r\n\t\\"returnRecords\\": 10\r\n}\"}",
it seems that , http-prompt add redundant file in the json content "file: {}" . I really dont need it.
source .bash_profile