But a good open source forms app would probably change everything, I would gladly stop my small project (in favor of contributing to an existing one for instance). I see there is integration with a lot of products, including Google Drive and Google Sheet.
Would an integration with Nextcloud be considered?
Congratulations on open sourcing this, we need open source and self hosted form solutions. Critically private data is put in forms and that get sent to big private companies like Google, which is not ideal.
As other commenters say, you might want to use AGPL indeed, but I guess you carefully thought this decision.
I am thinking of moving my volunteer org away from Google forms towards Grist.
> Would an integration with Nextcloud be considered?
We are definitely interested in exploring this possibility. However, since I am not personally familiar with Nextcloud, it would be helpful if you could provide more details. Could you please open an issue so that we can discuss it further?
But LimeSurvey has its advantages:
- it's in PHP, and our whole infra is already using it (WordPress and Nextcloud). So it's easier to setup and if we want bridges between these tools, it'll be easier.
- AFAIR, it doesn't require JS when filling a form and in particular, it's not a React app.
We have used LimeSurvey in the past, we got rid of it but I don't remember why, I should look into it another time.
Two other big requirements we have is solid conditional field support and easy to use form builder.
Can you go into that a bit more, I'm interested what you would see changing. Why do you think it hasn't been done already?
It wouldn’t change literally everything. The Sun and the Earth will continue to orbit around a shared barycenter. Humans will continue to breath oxygen. Carbon will continue to form four covalent bonds per atom. Some boys will continue to think a lot about some girls, etc etc.
I scrapped together a form-builder-with-payments using RoR and RailsAdmin last year for my club and ended up spinning it off into a pay-per-use SaaS[1].
As it turns out, forms are a fundamental aspect of a LOT of things, and offering free use tools can change the game for clubs or organizations looking to keep their data in one place.
Not every club charges dues, but those that do generally start off with a google form and a pinky promise that you'll send your dues after submitting the form.
Works for awhile but it's hard to maintain, speaking as someone who's had to do this before. embolt is my go at offering a member platform with a very low (the lowest) barrier of entry to getting up and running with paid registrations forms & an admin dashboard.
My ideal solution would be to send unique link to each recipient and limit one submission per link. However, I as a purchaser should not be able to see who got which link, or at least, how each link voted.
Question if heyform has some implementation of the need already, because none of the well known products - Google forms, MS Forms, Typeform - support anything like that
The 1st one is fine. The 2nd one says you would need to open source your modifications, but that would only be true if you also distributed your version rather than just using it on the server side. The 3rd adds three conditions. The first and third are again only true if you are redistributing the software. The second is an attribution clause that is not part of GPLv3, and the page to me definitely reads like it's explaining the license but not actually a license itself. GPLv3 does allow adding in similar conditions, but probably not those: I'm not sure requiring a link to the original project is ok.
AGPLv3 would be a much closer match to what the author appears to intend. It allows adding the attribution requirements that the author wants; see https://www.gnu.org/licenses/agpl-3.0.en.html section 7: "You may...supplement the terms...: (b) Requiring preservation of...author attribution..."
(IANAL, and every time I claim anything about licenses I get at least one detail wrong.)
Not in a uniform way - the license distributed with the code on github doesn’t have the extra conditions.
At this point I’d nuke the repo and force push with AGPL license instead, that seems a better fit.
In this case, I don’t see the actual license containing additional conditions, simply that the FAQ guidance on the page is misleading.
I see that it relies on mongodb, at a first glance this seems a good fit for a forms oriented product - looks like using a document db for actually dealing with documents. How did it work out for you? Would you choose it again?
Do not touch unless you understand how the license works and want to do so anyway.
It would be great if the license was used more. I'd much rather contribute to something where sharealike extends in some way across networks - software doesn't link in binaries, as the GPL does cover, as much these days.
You can in fact have GPL bw applied over network IPC even
Which is the license that you think it's safe to touch when you don't understand how it works?
In what ways exactly it is more dangerous than other open source licenses in this case?
only if you intend to produce a derivative work for which you intend to sell, and thus do not want to reveal said derivative to others.
AGPL is the best license available for open source imho.
In our organization, due to privacy reasons we need to self host.
You might want to look at something like the plus plan photoprism has. For photoprism, if you want a UI for user admin, you pay something. One can do the same thing from cli, but in corporate environments it's easier for me to say, look, we need to pay, because we need this admin interface. If I would self host but want to support you otherwise, it's hard to argue why the organization should "donate" money.
Hope it makes sense. Best wishes!
Thanks for bringing up the good question!
Please open an issue and let's discuss it further. With any luck, we can make it available in just a few weeks.
Could you please provide us with the name of the ISP so that we can contact them and request to have the ban lifted?
I would totally rather learn something like this that I can hack on. And when other people ask me how to do something for a Real reason, I would not hesitate to recommend the hosted version if it can do what they want. (No, I don't want to be on the hook for maintaining a self-hosted version of something that will be depended on for wide public consumption. I'm done with pager duty.)
The creators' hearts seem to be in the right place, so I'm less subliminally worried that they'll enshittify it in some way that bothers me. And if they do, the license gives me a way to proceed without starting with something new from scratch.
I'm building Formester and it is a lot of work to keep up a good form builder.
Wish you all the best.
> My manager let me know that due to my answers in the culture survey, they didn't think I was a good fit for the company anymore and were letting me go.
> said that my responses to the survey showed that I had a negative attitude about the company and that they wanted to part ways.
source: https://old.reddit.com/r/legaladvice/comments/67j04o/i_was_f...
This is my reasoning, I'm not the creator of this.
Sometimes, large companies open-source a SaaS product because they expect to make more money from the free marketing (See yesterdays post about headline-driven development) even though their implementation remains closed.
We still give them news-space, don't we? Why should we act any differently for solo developers?
Other organizations still, have open source only policies, or no open source at all.
Many of these applications can be in government.
It can increase the footprint.
As someone seeking a purely open source forms solution, what do you mean by this?
There is so much to unpack to get as why I have such an issue with it. But time and again I have been frustrated with it in terms of: it's design philosophy, implementation, scope of what it covers, bloat, recommended implementation approaches, etc.
I don't understand how a single framework can think that it should cover: message/request handling, logging, config management, dependency inversion, persistence, and IO. These things have almost no cross over (i.e. if they are well designed they should be easily composable with any other component) but time and again framework developers attempt to bundle them into a "one size fits all solution".
To best sum it up. I think any package I use should be secondary to my application. But this package makes it so that my application is secondary to the framework.
My go-to right now is itty router with zod.
Provider initialization (dependency injection) failed on me on a few occasions and it always wasted hours of productivity. It would break in some obscure way that wouldn't log any errors to the console, so there was nothing to go on besides attaching a debugger and stepping through layers of framework code. It was quite infuriating because it always happened when I was in the middle of something else.
If your specific use case wasn't covered by their docs (which were very barebones and "hello-world" oriented at the time), it was painful to figure out and use.
But like Angular, there is a very wide range of use cases where it is totally overkill and like Angular, companies are throwing it at each and every project.
I don’t find it bad but it’s in a strange spot being more bloated than other JS frameworks while still being way less "batteries included" than more classical corporate frameworks.
Like Angular, I don’t hate it though it’s just that I still haven’t figured out a project where it’s better suited than something else.
So some people will feel like it's over engineered.
I mean it's overengineered. Why do I have to register all these things, and why does it keep crashing if I register it like this without any understandable error message. It has a little bit of an OCD relationship with dependency injection. Where the normal import system can handle most of those cases.
But few nice things, resolvers, auto-generate swaggers. And TypeORM is lovely.
But yeah it's a bit too demanding. I'm okay with an opiniated framework if it gives a lot of features out of the box (like laravel or NextJs), but NestJS tells me how to do things without giving me enough in return. (auth, sockets etc are still quite a lot of work)
However, who wouldn't want to earn more? :D
Still sticking with server-side rendering though, always loved that approach to building webapps and tools like HTMX & Turbo make it much easier to integrate with complex UX interactions.
[1] https://medium.com/@csofiamsousa/hotwire-turbo-and-stimulus-...
Looking at the forums I can see that some have managed to achieve what you need via plugins (albeit the one I see that is confirmed working seems to be paid…)
Just thinking contributing an open source plugin to a great open source scripting tool would save you headaches down the road :)
I have not been satisfied with existing software, but I would be happy to find out otherwise.
I suppose in nextjs it's the only option?
Btw, itty-router v5 just dropped a couple days ago, with a fun batteries-included (still ultra-small) router, that should make your code even leaner.
How is the integration w/ zod anyway, and how can we make it better?
I'm in the progress of making a simple middleware based on zod to parse not only request body, but also params, headers, etc. Zod is really powerful and you could even use it to do stuff like parse jwt tokens and have complete type inference.
Perhaps my only issue with this approach is that you rely on a wrapper function to correctly pass the generics fron the middleware to the main handler.
Another possible approach is using types-per-route but then it's hard to enforce that the validator agrees with the handler itself.
I know of some CMS’ which were dual licensable for this reason.
Other reasons why:
https://www.channelfutures.com/connectivity/reasons-organiza...
As for the issue with CC, GPLv3 gives a 30 day grace period for rectifying violations which obviates many potential troll issues.
To me in most cases it is used it seems to just overengineer and obfuscate things unnecessarily when much simpler code would be easier to understand, etc.
It shouldn't be a thing that is done by default, only when it really makes sense.
Eventually with all those injections you are going to cause a situation where making any changes becomes really complex, if there are any use cases you didn't foresee at all.
In 90%+ cases you don't need interfaces and or DI, you should just be able to follow the logic with your IDE, it makes no sense to obfuscate that.
If the impl truly must vary for whatever case, then sure, you can use it.
But I would also say that don't do interfaces and impl before you actually need to switch them out dynamically depending on the context (and not just for testing).
If you have something that does Storage, and Storage drivers could be different like FileSystem, GoogleDrive, whatever, then sure use an interface, but not otherwise.
It's like DRY. Unless you actually use it 2-3 times, don't make everything unnecessarily into a reusable fn.
If you don't foresee having multiple storage methods in the near future then just use a class for storing which you can move to, to see how it does file storage or similar.