I think the SQLite model of contribution "Open-Source, not Open-Contribution" is a good middle ground to keep maintainer's sanity while having the code open [1]:
"SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."
The text you quoted is purely about copyright/licensing, not about the maintainers' sanity.
The more relevant quote is: "In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches from random people on the internet. There is a process to get a patch accepted, but that process is involved and for smaller changes is not normally worth the effort." Though this is still about copyright, not about being swamped with PRs.
The issue of the maintainers sanity is the onslaught of random people or LLM's submitting packages, So how is not both quotes equally valid for the intended outcome of describing the restrictions required as to collaborate???
You're right that the outcome may be similar, in that trivial contributions are discouraged. But the reasoning to getting there is completely different. Sqlite's copyright.html talks about copyright, not about maintainer overload.
An otherwise overloaded maintainer of another project may probably be willing to accept individual brilliant contributions from brilliant contributors. Sqlite will not, no matter how brilliant, if the contributor doesn't sign an affidavit. Independent of Sqlite maintainer load.
A known Sqlite contributor who has signed an affidavit, and has a history of good, accepted contributions, may also start spamming trivial contributions that may lead to maintainer overload, and nothing in copyright.html will prevent that.
Hi maintainer of Hurl here, thanks for the link; Hurl is using libcurl as its HTTP engine (you can for instance use --curl to get an export of curl commands). In a few words, if you just use Hurl, you just use curl also...
If you're willing to use a CLI, you can try Hurl [1]. It's is an Open Source cli using libcurl to run and test HTTP requests with plain text.
We use libcurl for the reliability, quickness and top features (HTTP/3 IPv6 for instance) and there are features like:
- requests chaining,
- capturing and passing data from a response to another request,
There is nice syntax sugar for requesting REST/SOAP/GraphQL APIs but, at the core, it's just libcurl! You can export you files to curl commands for instance. (I'm one of the maintainers)
Postman is currently down: it gives you time to try Hurl [1] an open source CLI to tests APIs/HTTP request s with plain text. Hurl is built on curl, so it's super reliable, designed to be used in CI/CD. Give it a try!
I'm sorry I must be really tired I don't understand certains animations when playing programs: in the first program, the 3rd instruction is 'PRINTI $0'. The instruction description is "print the integer stored in $a to the console". We have a first animation, a 0 that goes to the console, and a second animation, a 0 that comes from memory... Is the order right? What does represent the second animation? I must miss something obvious here....
Would be super cool if we could run programs step by step also!
The app is really super clean, I like it a lot (compare to Bruno for instance, one of your "competitor"). I see in the README that "Yaak is open source, but only accepting contributions for bug fixes.". It's an understandable statement, but it seems that there is also no way to post issues on the GitHub repo. Is there any reason for this (people could post issues without ever wanting to contribute imo). Anyway good job, I hope you'll get some traction!
We used Hurl to go from a ktor web server to a spring boot rewrite (Java/Kotlin stack). It was a breeze to have a kind of specifications test suite independent of the server stack and helped us a lot in the transition.
Another benefit is we built a Docker image for production and wanted to have something light and not tight to the implementation for integration tests.
Maintainer here, thanks for the feedbacks. 6-7 years ago, when we started working on Hurl, we started with a JSON then a YAML file format. We gradually convinced ourself to write a new file format and I completely understand that it might feel weird. We tried (maybe not succeeded!) to have something simple for the simple case...
I'm really interested by issues with the documentation: it can always be improved and any issues is welcome!
"SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. In order to keep SQLite in the public domain and ensure that the code does not become contaminated with proprietary or licensed content, the project does not accept patches from people who have not submitted an affidavit dedicating their contribution into the public domain."
[1]: https://sqlite.org/copyright.html