Thanks a lot for posting! Even though I had actually planned to post it later myself ;-) Happy to see my project finally live on hacker news!
n8n is a free node-based "Open Source" (Apache 2.0 with Commons Clause) Workflow Automation Tool. It can be self-hosted, easily extended, and so also used with internal tools.
Currently, there is no hosted version yet but you can sign up on the website if you are interested to get informed once it is ready.
I created it initially because I realized that every time I wrote a script to automate a small task it took me a very long time. Depending on the task it normally involved: reading documentation, writing code, committing to Github, deploying on a server, error reporting, SSL, make sure it restarts on a crash, and so on. So even very small tasks took at least half a day or day till everything was up and running properly. Existing Open Source solutions were not up to the task and also commercial ones like Zapier did not work for various reasons. Some being that they do not work well with in-house tools or complicated tasks and it gets expensive quite fast, ...
So hope n8n is as helpful for other people as it is for me. Also, all help with further improving the project and create more integrations is very welcome!
The project website with the nodes which exist and example workflows:
The whole project is written in TypeScript and uses Vue for the frontend. So it should be easily extendable for everybody with web development experience.
If you have any problems, questions or need an integration which does not exist yet you can post it to the forum:
http://community.n8n.io
All of the apps are "self-hosted". The marketplace just gives you one-click deploy to a VPS. It's especially convenient if you want to play around without committing to learn the setup bits. I haven't used the marketplace for any long term projects. But it's great for making MVP's.
Fantastic to see more people getting into this space, and even better to be able to inspect the source code!
Who's your target demographic here? I work at a place that was considering using Zapier, but couldn't because the security story around that service didn't really meet requirements we had around legal compliance/regulations (SOC, PCI, etc).
Having freely available source to audit + a good security story could make n8n very appealing for back-office enterprise workflows.
Thanks! Really great to hear!
It is actually one of my target audiences. Thought n8n has something to offer for kind of everybody. The three groups I had in mind were:
1. Private people and small Startups which care about the price
2. Medium-sized companies for which it is important to integrate their inhouse tools
3. Large companies/banks/government which care about their data
3. Large companies/banks/government which care about their data
As someone who left this space just two years ago and is now selling software into it I've been shocked by my users' appetite (appetites?) for self-hosted solutions. It makes me wonder whether SaaS will be short-lived and we'll see highly-regulated industries like finance and healthcare insisting data doesn't leave their servers unless absolutely necessary.
Depends on the org. Highly regulated places like self hosting because keeping data within your own network removes a lot of the legwork for corporate acquisitions processes.
If you run a SASS and a regulated business wants to use you, they need to process a whole slew of items:
1. Compliance - are you PCI/SOC/HIPPA compliant? When was your last audit? What were the results?
2. Legal - contracts, business continuity clauses, indemnity, liability around data, etc
3. Security - when was your last penetration test? Do you have a security team? What is your security posture?
The list goes on and there is overlap between different corporate concerns. Keeping things on-prem removes many requirements in exchange for taking on the maintainable burden of a product.
If you're a SaaS company that can't implement controls and governance systems to satisfy HIPPA, SOC2, etc, enterprises subject to regulation have no choice but to self-host.
Disclaimer: Worked at a SaaS company, now work in highly regulated financial services.
I'm confused, is it self-hosted or not? The website says that a self-hosted solution is on the way, but here you say it can be self-hosted already, and I can't find pricing on your centrally hosted version.
Interesting project, I like Zapier, and was interested in using this. — What about auto converting to GPL always 3? 4? 5? years into the future? So the current version of the project is guaranteed to become open source eventually, although it always starts as Commons-Clause for a few years.
Look at the Business Source license — they do that. (I'm doing the same with my project: AGPL —> GPL some years later.)
I thought about that. But did not decide yet as I first have to inform myself and think properly about what implications that could have. For example, could it mean a split of the community like what happened for Elasticsearch which is never good for any project.
Hey, as someone who works in non commercial, public health research, please consider using a license that doesn't penalise charities.
If you're using a dual license model, only rich organisations can use your software in security conscious industries like academic research (open sourcing our whole platform is far too expensive).
Please, please, pick a variant of AGPL that allows non commercial use.
I'm confused :- ) Who are you writing to? Me or @janober? Did you mean that n8n could switch to AGPL?
All versions of AGPL allow both non-commercial and commercial usage. (And one needs to share-alike one's modifications.)
In any case I like the idea to be free for charities and public research :- ) You work with something like that? Is AGPL ok with you, or you're worried it might require you to open-source parts of your platform?
AGPL requires all users to open-source their projects using your work, even if they don't modify your work. It is an extension of GPL not LGPL. If my web application uses an AGPL library, it's a derivative work.
I, like many in my field, work in a small team with almost no budget. My current project involves collecting sensitive (medical) data over the internet. The cost and risk involved in open-sourcing our application is prohibitive.
However, it's slightly less relevant for your project, as I can't see much value in directly integrating it into another application :) This is more a problem we run into with AGPL libraries, not AGPL applications.
Correct, you can buy the commercial license if you don't want to open source. This is a benefit of AGPL to the creators, and should you choose to open source your product, to the community as well. If you don't have the money, you can negotiate with the creator for the price. Note that this is a pricing/business problem and not a license problem. The creator, knowing your plight, may offer a commercial license for free, or a cheap, negotiated price.
I understand that developers need to earn money for their work. => Another license option to use is the the one of UI.Vision and others: Split the product in an Open-Source core (e. g. GPL license) and a proprietary part for the commercial "PRO" features of the product.
Yes is an option but one I would hate to take. It would mean that I have to artificially cripple the product for all users just to eventually earn money from a few. That was the opposite of what I wanted. I wanted that everybody can use it for free which gives the product the chance to get used by very many people and so become amazing for all users over time. So ended up with the Commons Clause as it aligned the most with my vision.
Thank you very much for creating this - I love it! :-D
I don't know about all the licensing stuff and will have to evaluate if I can use it for official business but I'm glad I can just use it for my own stuff in private without paying high fees.
Don't take the harsh critics about the licensing too personally - I think it's cool that you released your code and thought about Open Source licensing.
If you are unsure about if you can use it, simply explain what you want to do in an email to "license@n8n.io".
The goal with the license was not keeping people from using it. The main goal was to start it in a way to make the project long term sustainable which I thought would be in the interest of all people using it.
Also does not mean that people can never use it in a way which the license prohibits by default. It simply means that away has to be found which is beneficial to all sides. So just like anywhere in life.
You can already see it in the way it describes itself "Flow-based programming for the Internet of Things". So it is "programming" what n8n does not try to be. In Node-Red they give you as a guideline that you should not write high-level nodes if you can write lower-level ones instead (which could build the higher-level one when combined). Which is totally right for programming but not really to allow none coders to automate things. That is also the reason why there are no Asana, Pipedrive, ... nodes in Node-Red. It is simply not what it is made for. It is perfect for IOT applications but not for higher-level automation tasks.
n8n, on the other hand, is probably not the best choice for your IOT application.
So it is simply about using the right tool for the task at hand.
Node-RED targets a different market than this product and Zapier.
Loosely speaking Node-RED has a superset of the functionality this project has, sacrificing customization/generality for simplicity.
Zapier and n8n interface with the user via a catalog model.
Without needing to know what is going on behind the scenes or seeing any code, a person can follow a recipe and bolt together (certain) APIs to achieve business requirements.
The “certain” is an important to note because you will never achieve 100% coverage for your “API glue” for a mid size to large organization “out of the box” with any tool.
That being said, if using a tool like any of the above mentioned as a custom workflow engine (knowing you will be writing software from the onset) or as a solution and not a limiting factor or “silver bullet”, they can be very useful!
Other tools that can achieve similar results (using Directed Acyclic Graphs, where the nodes represent the execution of your code for a desired pre-programmed task) are Airflow, Flink, NiFi, Dagster, Dagobah, Celery, and many more.
I think "open source (but not really, there's a small restriction)" sums it up better than "source available", so I can understand framing it that way.
OTOH, this is likely to never make it into distro repos anywhere. I also wonder if the author is driving to make a business out of it.
So I'd make three points:
1) It does affect distribution
2) It otherwise doesn't materially affect how I would use it
3) It seems a little like asking for contributions to a proprietary project.
Source Available is pretty sweet if you have a paid product you'd like to do detailed audits on. Especially in regulated environments (finance, medicine, etc).
Many enterprises prefer a paid service, as such contracts usually come with somebody assuming liability for data on the system and being around to resolve problems you'd otherwise need to distract an in-house team with.
I agree. My point is more of "source available" undersells the freedoms it does give you, while "open source" just barely over-represents them, so I can understand framing it as "basically open source".
Conversely, Richard Stallman argues the obvious meaning of term "open source" is that the source code is public/accessible for inspection, without necessarily any other rights granted, although the proponents of the term say the conditions in the Open Source Definition must be fulfilled.
I fall into the "...conditions in the Open Source Definition..." camp. I think many "source available" projects ride on the coattails of the goodwill associated with the term "Open Source".
The capitalization of "Open Source" makes it a proper noun or adjective which means it refers to a specific thing. This is why the Open Source Initiative (OSI) always uses "Open Source". You know they are referring to open source as defined by them. "open source" would be referring to the general concept which depending on interpretation could include shared source.
In my view using the proper vs common version of "open source" places this into a disingenuous attempt to be associated with open source as defined by the OSI.
In my view responding immediately with clear clarification of the degree of the code openness, right under the title of the website, places this into this as something which isn't remotely disingenuous. In my view seeing this as disingenuous is, quit frankly, odd.
It is also goes against the site comment's guideline (as well as general sane rule) of: Assume good faith.
I wouldn't pay much attention to such statement knowing the historical background. Stallman was and is a proponent of his own terminology, i.e. "free software", and the related definition which actually isn't that different (hence the catch-all "FLOSS").
Anyway, it's stupid to argue over this. The FAQ on the Commons Clause site itself, reflecting the intention and thinking of the drafter and the initiatiors, specifically states the license is "source-available", not "open source". When talking about open source as a form of licensing as opposed to e.g. software development culture/methodology, the distinction here is quite widely accepted and non-contentious.
Most companies will require legal approval anyway before you are allowed to use it.
For instance, at a previous company we were forbidden to use React until Facebook changed over to the MIT license. Facebook had a poison pill buried into their original "open source" license.
So to make it simpler do I hereby grant anybody the right to do consulting/support without prior permission as long as it is less than 30.000 USD per year.
That seems pretty fair - avoids the issues of freelance work being done with the project. I find it hard to care about big corporations not having access to monetize it but that begs the question - doesn't this reduce possible hosting solutions? Especially since there's no official hosting. Does this license imply that there can't be 3rd party commercial hosting?
If the only thing being offered is the product, but as part of an automated pipeline, from my reading of the license it could go either way, depending on the judge hearing the case.
That wouldn't be a very comfortable legal position.
I am not an IP lawyer, but I'm not sure that you can monetize this project either the way it's currently set up? Since you're accepting third-party pull requests without requiring a copyright assignment or more permissive license from the contributors, I believe that you'll only be allowed to use their contributions under the Apache-with-commons-clause license they submitted their work under.
Yeah, that seems like a glaring issue. What's the goal of the license? If not to encourage contributions and building other things on top of it, seems more like a "shared source" license. Might make more sense to make at least part of it fully open source, for everyone to contribute to freely (in both directions) and perhaps keep a smaller part (semi) proprietary.
Is this not a controversial topic? As far as I know there are two camps (as is alluded to further downthread) on whether Open Source is literal, or implies more about the license.
I favour the "open source = source available" definition, because that's how most people will understand it anyway. But regardless of where you stand on this, I think it's fair to say it's at least controversial.
I favor the "source available = source available" and "open source = open source (by the commonly understood open source definition)". It's much clearer that way, and wasn't really a muddy issue until certain big software companies started using "open source = source available"
Having to define "open source" with that addendum illustrates the issue quite apropriately.
"Open Source ≠ open source" is the essence of the problem. The source is open, yet it isn't open source.
Here's an experiment you can run: hold an informal survey amongst a representative subset of programmers. "What does open source mean?". See what they say. I think I met one who knew what the OSI was.
Ironically, "free software" is a similarly terrible term. It should be called "freedom software". I once e-mailed Stallman to ask about it, and he replied they couldn't use that term because it was already trademarked. Welp...
Commons Clause does not meet OSI's definition of "Open Source" nor the GNU/FSF definition of "Free Software" so it's fair to say it should not be called either.
Yes, it doesn't fit either definition, so it shouldn't be called either.
The term 'free software' is hard to keep 'pure', because it has an obvious meaning for people who know nothing about software licensing.
But IMO, the terms 'libre software' and 'open source' should not be diluted. It doesn't serve any purpose to mis-use those terms, except confusing everyone.
Prescriptivism is a policy you can choose to follow, but I don't subscribe to it. I'm a descriptivist through and through. And from what I understand, I'm not the only one.
The very language I'm writing this to you in is probably the world's most exemplary instance of this principle in action.
Besides, isn't using things in other ways than they were originally intended the essence of The Hacker? ;)
I work two days a week for a startup to earn my living and the other time I spend on other projects like n8n. That is why progress is not always as fast as I hope it would be. That is why I also hope to make money with n8n as some point to work full time and make real progress.
Yes it was and still a lot left ;-) But it was worth it as it helps me now every day and will hopefully from now on do the same for other people as well!
Zapier has about 1,000 integrations, more than any of their closest competitors and at a price that is far less than others in their space. What you've done here is great! The UX seems better than Zapier and the extensibility & community approach terrific. The key, though, is going to be adding integrations rapidly. I might also stress:
- Bulk actions.
- Sync actions.
And support for other programming languages (eg. python)
Not really. The integrations are node-up, meaning the SAAS creates its own integration as value-add to its customers; and there's some user growth that emerges from being in their catalog. But, you point is somewhat valid in that many of the integrations tend to be shallow - so apart from a few key functions it can be tough to use them for complex workflows.
N8n.io looks amazing. I would absolutely switch over to this if there were more integrations! (Namely: Shopify & Zoho Mail)
Half-tempted to dive in and see if I can code something up, but I need to focus on other parts of my business and not dive down the scratch-my-itch dev rabbit hole (again).
Thanks a lot! It would be amazing if you would create those integrations but can understand if you have different priorities. In this case, simply add the integrations you need as a request to the forum. Other people can then upvote them and I know what to work on next. For example, already created a request for a Shopify integration myself a month ago which you could simply upvote:
https://community.n8n.io/t/shopify-integration/22
Good god Jan, you are amazing! Liked what you did with "link fish" and "ninja crib" but this takes things to a whole new level. I would love the chance to learn from you!!!
Congrats, I'm pretty sure this project will be a big success
Thanks a lot! But probably not the right person to learn from. But that is one of the great things about the internet that you can now really always learn from the best people in their field thanks to Udemy & co.
I love how you licensed it. I'm seeing a trend in how developers are being thoughtful about the licensing and how it will help monetize their efforts later. Excited to see how this goes.
Likely badly - this doesn't meet the OSI open source defintion, and while interesting, many developers are reluctant to contribute to various shared source / source available proprietary core products.
I can totally understand if a person says "I do not want to contribute code to a project for free when somebody else can make money with it".
But then they can not contribute code to any OSI approved Open Source licensed project. Because with that license everybody can make money with it. And very often is that somebody the wrong one (like for example Amazon).
The only difference with the Commons Clause is that now still somebody can make money. But that somebody is now the entity behind the project. And they normally put that money right back into the project (by for example hiring developers) and make so sure that it improves and stays around a long time.
So I personally would prefer to contribute code to a project which uses the Commons Clause then one which does not.
Thank you for picking the license you did. Developers should be able to earn from their hard work, versus having a Goliath cloud provider take it and profit from it without contributing anything back. No need to cater to potential contributors who have no skin in the game, but turn their nose up at a license they don't believe in.
I can totally understand if a person says "I do not want to contribute code to a project for free when somebody else can make money with it"
It's not so much that somebody can make money with it. It's that you, the project maintainer, will be reaping all the monetary benefits for yourself. With open source software theoretically anyone can benefit. If you don't like what the maintainer is doing, you can fork it. In this case, though I believe the commons clause does allow you to fork it, you would still be the one reaping any monetary benefits from the fork.
In my opinion the biggest issue with the commons clause is it no longer makes logical sense to fork the project. If the project dies because you couldn't make any money off it, and you don't go back and relicense your work, the code is practically dead as an 'open source' project. Well, that and that the consulting clause seems to be just sitting there waiting for a major court case to decide what it truly means (even the lawyer who led drafting the clause admitted as such [1]).
If it dies, there can be a point where the maintainer can re-license under more open terms, no? Until that point, the work and contributions are ensured to help sustain the creator.
I'm planning on releasing my project under similar terms. I'm not particularly interested in community contributions, but rather for there to be trust in ensuring privacy and security. Sometimes, there isn't a one-size-fits-all with the available OSI licenses and I appreciate what op has done to do his best to find what works well for him and the community.
It's less a community in that case than potential customers. Your creating a product, which is fine, but words like 'open source' and 'community' are quite misleading.
The words 'community' and 'customers' are not mutually exclusive and using the word community to refer to your customers is not misleading in the slightest...
I'm not sure sure it will go "badly". I believe there's a fundamental issue with a class of software applications that the current OSI licenses don't do much for. Let me clarify that statement with some examples. If you're a developer of an "open source" library or database engine, you have great OSI licenses available to use. The consumers of your work will either open source their work or purchase a license (i.e. dual-licensing). If, however, you're creating a CMS or some standalone tool (like GIMP, for example), you're left to go down the road of open core (typically). So, the alternative here is to choose a license that's conducive of being able to monetize without depending on donations or support contracts.
I think developers should pick a license that makes sense for them, not necessarily for the benefit of others. What is important though, is that some thought is taken and to try it out. You can always go more permissive later.
I'm working on something that I want to monetize, but the OSI licenses aren't helpful for the kind of application I'm working on. I'm leaning towards a similar licensing structure and have been spending a great deal of time thinking about this and I hope to have more discussions on this very topic as it's extremely helpful for everyone.
I really don't like when people say they are the "x" of "x" or the alternative to "x", doesn't that just drive people to look at "x". Sure it gets the idea across but there are other words to do that. Otherwise, great looking product
It's not always that cut and dry. If X is already well known, it actually has the opposite effect -- it capitalizes off of X's brand and familiarity and drives people to the new product. It's a common technique (that is frequently misused) in marketing and advertising.
I don't know if X=Zapier here is that effective, but I recognized it right away, and clicked the link to learn more.
This really looks like a great software and seems that the guy behind it knows what his doing. Additionally being open and fair about the licence. I will try it ASAP and wish the project gets BIG.
Look awesome, and although the license is definitely NOT open source (although you DO say the parts that people care the most are best-effort open source to the community), this has the potential to motivate other people to work on similar projects or suggest improvements to yours.
However...
The beauty of Zapier relies on its amount of pluggable blocks. I don't think there's anyone in this market that has as many operations as Zapier and using custom blocks you can do pretty much anything. Yes I am totally a fan of Zapier as I have been using it for years!
Zapier is like LEGO, there are many clones of LEGO but only one true LEGO (ouch my feet hurt just by thinking about it ;) )
I really hope you can get people to contribute more and more integrations as that's what really matters at the end of the day: The ability to use little or no-code to achieve automation between various platforms!
Zapier is propietary and prohibitively expensive. Yes, I like it -- but I'd rather support small projects like this one, even if it requires a bit more of time.
Super happy to see this effort and eager to check the code out soon!
As someone who relies on a lot of Zapier-style API connections, I’d love to hear more about how people approach it - how you go about managing env vars (keys/token), abstracting similar service procedures (oauth, webhooks) and generally monitoring 3rd party API endpoints for keeping the connections healthy? Any advice from Zapier / IFTTT veterans?
Edit: the n8n docs seem good and also address most of my questions [1]
Yes, any advice would also be very appreciated from my side.
Great to hear that the docs are helpful! They were actually the main reason why I did not launch on Product Hunt/Hackernews earlier. It was very important for me to have something in place which is at least reasonable. Nothing more annoying than bad docs. Anyway, still a lot on my list to add documentation for. But it will get better, I promise!
Cool project. One aspect of these integration systems is that the volume and velocity of integration development is one of the main ways they show value. Zapier claims 1500+ integrations, and they have many competitor with similar counts of integrations. Somehow, they always seem to not have that thing I need.
I wonder why, in this era of Swagger / OpenAPI / Postman Collections / API Gateways ... why this is so difficult? I feel like there was a promise that integration would become more magical at a rapid clip, but as it stands it just seems like there are more options but no less headaches.
A lot of APIs don’t support the tooling you mentioned, have all sorts of rough edges (return improper http codes, or don't return them at all), or act...quirky at scale (based on my experience at an automation workflow org).
Of course, as APIs improve (OpenAPI, etc), the barrier to entry for all workflow tools declines (which is a good thing!). You're then just serializing and deserializing JSON (or a mutation thereof) between two or more steps. Just as Google makes their Terraform provider a first class citizen by autogenerating the Terraform provider based off of their APIs (Hashiconf 2018 SF talk), so could integration partners for workflow automators. Just takes time for the ecosystem to mature.
Thanks for sharing, that is definitely compelling. I like that their integrations cover lots of API methods, whereas a lot of simpler services only cover a few.
From other comments in this thread, it's apparent this is "source-available" but not "open source" in the sense of a free software [0] or OSI-compatible [1] license.
But the usual benefits of free software, like what has been possible with the Linux kernel, GNU software, and so much more, are not going to be possible to the same degree with this software.
Thanks for this! I was just yesterday looking for good workflow automation tools, and was leaning towards Huginn, but I will definitely check this out.
Great to hear! If you have any problems simply post them in the forum I try to get back to you asap (sorry, will maybe be right ow longer than normal as I have a lot to follow up right now).
Crowded space, but darn few (if any) shared source or community based solutions. Here's a several examples from a market study I did in 2018: Workato, Apiant, Inegromat, Snaplogic, CloudHQ, Boomi, Tibco, Jitterbit, AWS Lambda, Mulesoft, Tray.io, ApacheNiFi, Stringify, Adeptia, Kotive, Cazoomi, Scribesoft and several more.
I work at Boomi, on their Flow product (similar to this project), and we open source everything in our product, except for our core workflow engine - https://github.com/manywho (our pre-acquisition name if you're wondering).
The community part is hard to generate though... there's a lot of enterprise in the workflow space.
StandardLib also has a community, though not sure how big it may be.
Pricing is a key differentiator. My market research included a pricing analysis and Boomi was priced well above Zapier and other similar solutions.
I think there is a LOT of money ceded to less expensive offerings by 10 or 15 providers (including Boomi) all chasing the same enterprise market. I would've expected tiered pricing to emerge to a greater extent, but haven't seen it.
It’s maybe a dumb question but even after looking in some of them I usually fall back on a classic cron job + some Python scripts for automation for the flexibility. What’s the biggest advantage of these services / solutions when you already have some servers available?
Which one in your opinion allows for extensions of those APIs the best at a SMB price point? My frustration with Zapier is that I if they don't support the trigger, I'm kinda sol. I wanna be able to say "I want to manually add this API call" in a low code environment.
Also - do you mind if I grab some of your time to discuss on the phone? my contact details are in my profile.
question: if I have a project management software saas, and I want to integrate n8n to make automations (for example: when a task is marked as completed), is the license valid for this use?
I'm one of the people who subscribes to the Open Source Initiative's definition[1] of the term "Open Source". On that basis, the "Commons Clause" applied to the license of this software discriminates against fields of endeavor. This makes it a "source available" license to me, and not an "Open Source" license.
I hereby grant anybody the right to do consulting/support without prior permission as long as it is less than 30.000 USD per year.
technical note: USD uses commas to denote thousands. So, in USD 30.000 == $30 which isn't worth the time spent to do the research to pick up the first phone call.
Social note: in many US cities $30k isn't enough to survive. In the US it's certainly not enough to live _well_. So, you're basically saying "Hey, I give you permission to make an important contribution to the success and community of this project as long as you're willing to take an absolutely CRAP salary for it."
that's.... not really cool.
I don't think it should matter how much a support person can make supporting your project. The only way a support person will be crazy successful financially is if your tool is ALSO crazy successful. It's a mutually beneficial situation. Don't limit them. Their success is your success.
If you are running a consulting/support business and have your customer download the software then this clause is likely not even enforceable. You would not be distributing or running the software and therefore would not be subject to the terms of the license.
I guess so yes. At the same time, if someone installs and helps their customers with n8n, in addition to some other bigger more "main" things s/he does, then $30k can be fairly much?
If it's not the contractor's main thing but a smaller part of his/her offerings? ... O.t.o.h. maybe s/he never gets really good at n8n if s/he won't focus on it full time.
Sorry for the confusion. The 30k was just some random amount to make it easy for most people. And did honestly not expect that a lot of people's income would come to 100% from n8n. Thought it would be one of multiple things they do and so 30k seemed like more than enough to cover the majority.
Additionally did I not mean that they can ever make more. I simply wrote that up to that amount they do not even have to say anything. In the next sentence it additionally says:
"If you have bigger things planned simply write an email to license@n8n.io."
HN usually finds a theme to complain about with any cool project. Looks like this time they picked licensing. Just wanted to say thank you for making this project. I think tech like Zapier/IFTTT are really cool, but I would never trust a closed platform of this sort.
But something like n8n I would consider using, because you've provided an escape hatch to lock-in by making the source available. I think it's totally reasonable to prevent other companies from profiting from your work. I also think it falls under the umbrella of "open source". If someone wants a truly FLOSS version of this, they're welcome to make it themselves. But they won't, they'll just complain and keep using n8n, because the licensing is good enough for 99.9% of use cases.
EDIT: I just want to point out that there's been some discussion of licensing here which I've personally found interesting and instructive. I've seen several people suggest that there is a definition of the term "open source" that is essentially universally agreed upon (that being the Open Source Initiative definition [0]), and that that is the only valid definition. I've worked in what I consider to be open source for many years, and wasn't aware that such consensus had been reached. My personal views have not changed as of yet, but my paradigm has definitely shifted. I intend to pay closer attention to how others use this term, and carefully attempt to be clear about my usage in the future. Having a single agree-upon definition of things is always valuable, and if that's where we're at I'm all for it. I'm just not convinced yet that it's actually 100% agreed upon.
That said, I think the author of n8n was pretty dang clear.
There's a weird trend on HN. For proprietary products (e.g. slack) I rarely see them getting criticized for having a proprietary license. If you are fully open source, then of course they love you. But if you try to strike a compromise and give away a lot while still keeping some licensing terms to let you make money off your creation, then you'll be bombarded by complaints about your licensing.
If Microsoft started calling Windows open source, I would be pretty peeved too. The word open source here is used as a marketing term for a product that isn't in spirit or reality. Yes, the source is available; that's nice, but it's not the same.
Windows isn't free. Nor is the source available to be viewed, modified, extended, learned from, etc. Also, you're comparing one of the biggest tech companies in the world, to an individual who is trying to make a living. This is an unfair characterization on every level.
Windows isn't free. Nor is the source available to be viewed, modified, extended, learned from, etc.
I mean, I'm just using a popular non-open source piece of software as an example, you don't really have to read into it this much. Every comparison has limits, this isn't any exception. You can substitute 'Windows' for 'Gitlab EE' which is also proprietary software with available source code.
Also, you're comparing one of the biggest tech companies in the world, to an individual who is trying to make a living. This is an unfair characterization on every level.
The depth of someone's pockets doesn't influence the definition of open source, though. This is not a characterization at all, rather, I'm saying that using the word open source to describe software that doesn't meet the criteria is always going to upset people. There is a simple solution that costs no money: removing the word open source. It is even recommended by the folks who push common clause.[1]
I realize people are very passionate about this, but please try not to read into what I'm saying too deeply.
(Also very notably: I have absolutely NOTHING against proprietary or shared source software, or developers making money; love Gitlab EE as an example. Just please be honest.)
Well...characterizing the usage as a marketing term wouldn't be relevant if the potential for making money weren't an issue here.
Even beyond that, on a human level, the attacks on an individual trying to make a living seem unnecessarily harsh. My critique is mostly about the spirit of the negative comments (not just yours, sorry), which all seem to assume malice where there likely is none. I.e. several comments here and on the github repo calling the developer a liar and coward, etc (again, not you, this just happened to be the comment I replied to)
And I think this entire discussion proves that the definition of 'open source' is not as cut and dry as some people would like. And because of that, saying 'just be honest' when someone uses one of the alternative definitions of the term seems unfair.
I've always thought that the terms FOSS exists specifically to provide some extra clarity in this regard...
And I don't know what you'd call this other than "open source" because I haven't heard the term "source available" until today, and I would have had no idea what it meant if that's what the developer had used....
Well...characterizing the usage as a marketing term wouldn't be relevant if the potential for making money weren't an issue here.
There is nothing wrong with marketing a project, be it open source, proprietary, free, non-free, etc. I never suggested that. Just about everything is 'marketed' in some sense.
Even beyond that, on a human level, the attacks on an individual trying to make a living seem unnecessarily harsh. My critique is mostly about the spirit of the negative comments (not just yours, sorry), which all seem to assume malice where there likely is none. I.e. several comments here and on the github repo calling the developer a liar and coward, etc (again, not you, this just happened to be the comment I replied to)
It's because there's a lot of passion involved. Even people who are pretty great open source developers have acted in a way that is perhaps not so noble if you read the flagged comments.
However, I don't think this is necessarily out of assumption of malice. The problem is, it doesn't matter if the author is malicious or not. The term 'open source' carries some connotations that many people have an intuitive understanding of today. I firmly believe the very reason a lot of big projects choose open source is for the marketing benefit, and imo it is not deserved if your project isn't really open source. This could seriously harm the reputation of something that took decades to build, and if that seems alarmist, well, I know I'm not alone in this sentiment.
And I think this entire discussion proves that the definition of 'open source' is not as cut and dry as some people would like. And because of that, saying 'just be honest' when someone uses one of the alternative definitions of the term seems unfair.
I've always thought that the terms FOSS exists specifically to provide some extra clarity in this regard...
I don't know what you'd call this other than "open source" because I haven't heard the term "source available" until today, and I would have had no idea what it meant if that's what the developer had used....
The thing is, if I say something is 'open source,' you almost certainly, today, will understand that to mean what it has meant for decades: the OSI definition of open source, contrary to the wishes of some (including rms, for example.) This is just the layperson's understanding. They may not have a deep understanding of licenses or permissiveness, but it comes with a sense of what a project has to offer. Being able to profit off of open source is something that people inherently understand nowadays, and it took a long time for that to happen.
The reason you wouldn't have understood another term is because there is not a common understanding for 'source available' or 'commons clause.' This is because it was not very popular in recent years, and remains relatively unpopular. It is mostly pushed by companies that built amazing open source projects and had trouble with creating a sustainable business around it.
And therein lies the contention.
- Because of what Open Source implies, it gives projects a decent marketing boost - including, of course, the common case where they are truly open source. People rely on open source projects understanding the implications and knowing roughly what they can do with it.
- Commons clause doesn't imply the same things. But some companies are trying to use the term 'open source' to describe them anyways. To me, this looks a lot like trying to have cake and eat it too. It's not the same 'open source' that people have slowly grown to understand.
Of course most people won't understand why this issue has much contention, because this type of thing seems like a minor detail. In fact, many people, including me, initially found it confusing that licenses like GPL allow you to profit off the work so as long as you follow the other clauses. It took me a long time to understand that this is a very important part of what makes open source special: the disconnect from the profit model. If you reconnect the development and licensing to the profit model, in my mind this is losing a key part of what makes open source so damn effective. Having many stakeholders that all profit from a project can be incredible - the Linux kernel being one such example.
People have to make money, though, and so going through the risky proposition of making truly open source software and trying to build a business around it is not always appealing. In my opinion, the obvious choice is to not make open source software. So-called "commons clause" is one option. But again, I think there is real danger in "open source" being conflated with things that nobody understands it to be.
I don't think it's particularly weird, it's about misrepresentation. Most users attracted to open source licensing aren't aiming for abstract goals like "give away a lot" or even "give away as much as possible", they're aiming for "give away practically everything so they can use it for free in any way they want". Proprietary products don't waste these users time as they are clearly not suitable, but advertising an open core product as open source will attract a lot of unsuitable users who desire open source when you're offering open core.
If you're trying to make money, just don't do open source. No one owes you kudos for striking a compromise no one wants.
In terms of the licensing debate... Did you bother to actually read the Common Clause FAQ? Here are the first 2 FAQ entries:
"What is Commons Clause? The Commons Clause is a license condition drafted by Heather Meeker that applies a narrow, minimal-form commercial restriction on top of an existing open source license to transition the project to a source-availability licensing scheme. The combined text replaces the existing license, allowing all permissions of the original license to remain except the ability to "Sell" the software as defined in the text.
This Clause is not intended to replace licenses of existing open source projects in general, but to be used by specific projects to satisfy urgent business or legal requirements without resorting to fully "closing source".
Is this “Open Source”? No.
“Open source”, has a specific definition that was written years ago and is stewarded by the Open Source Initiative, which approves Open Source licenses. Applying the Commons Clause to an open source project will mean the source code is available, and meets many of the elements of the Open Source Definition, such as free access to source code, freedom to modify, and freedom to re-distribute, but not all of them. So to avoid confusion, it is best not to call Commons Clause software “open source.” "
This is really neat! I'm generally prohibited from using stuff like Zapier at work, since we handle a lot of client data and passing it through any third party opens up a Pandora's Box of legal reviews. The self-hosted nature of this would bypass a lot of that hassle.
Public Service Announcement for anyone at BigCorp: Microsoft has it's own tool in this space called Microsoft Flow[1]. It's not as feature-filled as Zapier, but it works in a pinch and you get access to it automatically as part of an Office/Microsoft 365 license. So unless your corporate IT has gone to great lengths to explicitly disable access to it, you can leverage it to make your life at least a bit easier.
This reminds me a lot of a visual code based data processing tool developed out of the NSA. Apache NiFi. The difficulty with all these low/no code environments is getting scale and maintaining enough widget blocks for it to be productive quickly.
I've seen enough of these supposedly non-programmer-friendly interfaces to judge them all guilty until proven innocent (not that many, to be honest, but I am scarred nonetheless). Looking at the video, it's not the worst I've seen. But please, I beg you (the authors here or anyone building a similar product):
- Provide first class debugging and dry-run support. Don't make people either run in prod (as the demo video effectively does) or set up full testing environments.
- Strict, comprehensible scoping rules. Non-programmers will have more, not less trouble with having named data propagated everywhere for reasons that aren't visually clear. Global state is still bad.
- Don't make users think about JSON.
- Supply auto-layout. Don't force users to manually reposition things to get a decent layout, and ideally don't let them. The demo video seems to show at least the first half in place, so that's good.
- Version control. Possibly via...
- Ideally an isomorphically editable text representation. You can switch between graphical and text representations and have changes propagate.
Maybe this project checks more of these boxes than I've seen so far. I'm pathologically optimistic, so there's a good chance I'll work with this enough to find out.
I don't really know why everyone wants to keep making these benighted flow-chart UIs instead of using the relatively proven Scratch UI model.
I'm curious - could you explain what you mean by the "Scratch UI"? I did some searching on Google, but there appear to be several products which use this term.
Leaving the UI aside, how is this different from Huginn? I have a few Huginn agents running menial tasks, but I find time consuming to debug issues. Does N8n have more connectors? What are the strengths compared with Huginn?
Thanks a lot for posting! Even though I had actually planned to post it later myself ;-) Happy to see my project finally live on hacker news!
n8n is a free node-based "Open Source" (Apache 2.0 with Commons Clause) Workflow Automation Tool. It can be self-hosted, easily extended, and so also used with internal tools. Currently, there is no hosted version yet but you can sign up on the website if you are interested to get informed once it is ready.
I created it initially because I realized that every time I wrote a script to automate a small task it took me a very long time. Depending on the task it normally involved: reading documentation, writing code, committing to Github, deploying on a server, error reporting, SSL, make sure it restarts on a crash, and so on. So even very small tasks took at least half a day or day till everything was up and running properly. Existing Open Source solutions were not up to the task and also commercial ones like Zapier did not work for various reasons. Some being that they do not work well with in-house tools or complicated tasks and it gets expensive quite fast, ...
So hope n8n is as helpful for other people as it is for me. Also, all help with further improving the project and create more integrations is very welcome!
The project website with the nodes which exist and example workflows:
https://n8n.io
You can find the source code on Github: https://github.com/n8n-io/n8n
The whole project is written in TypeScript and uses Vue for the frontend. So it should be easily extendable for everybody with web development experience.
If you have any problems, questions or need an integration which does not exist yet you can post it to the forum: http://community.n8n.io
Documentation can be found here: https://docs.n8n.io
Your feedback is highly appreciated!
Thanks a lot!!
UPDATE:
[Sorry are unable to answer any questions right now as it always displays me that I am posting to fast. Will answer as soon as HN allows me!]
Looks neat! FYI you have a typo on https://n8n.io/hosting you probably meant to s/self-hosted/hosted/
Thanks a lot for the info. Is fixed!
I'd love to see this on DigitalOcean's app marketplace for self-hosting.
https://marketplace.digitalocean.com/category/all
Interesting resource. But, how do you filter for just self-hosted... I can't find that as a specific category.
All of the apps are "self-hosted". The marketplace just gives you one-click deploy to a VPS. It's especially convenient if you want to play around without committing to learn the setup bits. I haven't used the marketplace for any long term projects. But it's great for making MVP's.
Fantastic to see more people getting into this space, and even better to be able to inspect the source code!
Who's your target demographic here? I work at a place that was considering using Zapier, but couldn't because the security story around that service didn't really meet requirements we had around legal compliance/regulations (SOC, PCI, etc).
Having freely available source to audit + a good security story could make n8n very appealing for back-office enterprise workflows.
Thanks! Really great to hear! It is actually one of my target audiences. Thought n8n has something to offer for kind of everybody. The three groups I had in mind were: 1. Private people and small Startups which care about the price 2. Medium-sized companies for which it is important to integrate their inhouse tools 3. Large companies/banks/government which care about their data
As someone who left this space just two years ago and is now selling software into it I've been shocked by my users' appetite (appetites?) for self-hosted solutions. It makes me wonder whether SaaS will be short-lived and we'll see highly-regulated industries like finance and healthcare insisting data doesn't leave their servers unless absolutely necessary.
Depends on the org. Highly regulated places like self hosting because keeping data within your own network removes a lot of the legwork for corporate acquisitions processes.
If you run a SASS and a regulated business wants to use you, they need to process a whole slew of items:
1. Compliance - are you PCI/SOC/HIPPA compliant? When was your last audit? What were the results?
2. Legal - contracts, business continuity clauses, indemnity, liability around data, etc
3. Security - when was your last penetration test? Do you have a security team? What is your security posture?
The list goes on and there is overlap between different corporate concerns. Keeping things on-prem removes many requirements in exchange for taking on the maintainable burden of a product.
If you're a SaaS company that can't implement controls and governance systems to satisfy HIPPA, SOC2, etc, enterprises subject to regulation have no choice but to self-host.
Disclaimer: Worked at a SaaS company, now work in highly regulated financial services.
I'm confused, is it self-hosted or not? The website says that a self-hosted solution is on the way, but here you say it can be self-hosted already, and I can't find pricing on your centrally hosted version.
It is self hosted - he hasn't released a hosted version yet but would like to.
The source and documentation for setting it up, using it, and developing with it are already available.
Sorry there was a typo on the "hosting" page. Got fixed in the meantime.
Interesting project, I like Zapier, and was interested in using this. — What about auto converting to GPL always 3? 4? 5? years into the future? So the current version of the project is guaranteed to become open source eventually, although it always starts as Commons-Clause for a few years.
Look at the Business Source license — they do that. (I'm doing the same with my project: AGPL —> GPL some years later.)
Best wishes :- )
I thought about that. But did not decide yet as I first have to inform myself and think properly about what implications that could have. For example, could it mean a split of the community like what happened for Elasticsearch which is never good for any project.
Hey, as someone who works in non commercial, public health research, please consider using a license that doesn't penalise charities. If you're using a dual license model, only rich organisations can use your software in security conscious industries like academic research (open sourcing our whole platform is far too expensive). Please, please, pick a variant of AGPL that allows non commercial use.
I'm confused :- ) Who are you writing to? Me or @janober? Did you mean that n8n could switch to AGPL?
All versions of AGPL allow both non-commercial and commercial usage. (And one needs to share-alike one's modifications.)
In any case I like the idea to be free for charities and public research :- ) You work with something like that? Is AGPL ok with you, or you're worried it might require you to open-source parts of your platform?
You! :)
AGPL requires all users to open-source their projects using your work, even if they don't modify your work. It is an extension of GPL not LGPL. If my web application uses an AGPL library, it's a derivative work.
I, like many in my field, work in a small team with almost no budget. My current project involves collecting sensitive (medical) data over the internet. The cost and risk involved in open-sourcing our application is prohibitive.
However, it's slightly less relevant for your project, as I can't see much value in directly integrating it into another application :) This is more a problem we run into with AGPL libraries, not AGPL applications.
Correct, you can buy the commercial license if you don't want to open source. This is a benefit of AGPL to the creators, and should you choose to open source your product, to the community as well. If you don't have the money, you can negotiate with the creator for the price. Note that this is a pricing/business problem and not a license problem. The creator, knowing your plight, may offer a commercial license for free, or a cheap, negotiated price.
I see some integrations related to functions. Could you use this as some sort of a self-hosted alternative for AWS Lambda or CloudFlare Workers?
Hard to answer that in a general sense. It depends a lot on how you use AWS Lambda. In most cases, I would say no. But possible for a few.
Commons Clause is not Open Source. It is free-of-charge (for certain uses) source-available proprietary software.
I understand that developers need to earn money for their work. => Another license option to use is the the one of UI.Vision and others: Split the product in an Open-Source core (e. g. GPL license) and a proprietary part for the commercial "PRO" features of the product.
Yes is an option but one I would hate to take. It would mean that I have to artificially cripple the product for all users just to eventually earn money from a few. That was the opposite of what I wanted. I wanted that everybody can use it for free which gives the product the chance to get used by very many people and so become amazing for all users over time. So ended up with the Commons Clause as it aligned the most with my vision.
Thank you very much for creating this - I love it! :-D
I don't know about all the licensing stuff and will have to evaluate if I can use it for official business but I'm glad I can just use it for my own stuff in private without paying high fees.
Don't take the harsh critics about the licensing too personally - I think it's cool that you released your code and thought about Open Source licensing.
Keep up the great work!
Thanks a lot. That is great to hear!
If you are unsure about if you can use it, simply explain what you want to do in an email to "license@n8n.io".
The goal with the license was not keeping people from using it. The main goal was to start it in a way to make the project long term sustainable which I thought would be in the interest of all people using it.
Also does not mean that people can never use it in a way which the license prohibits by default. It simply means that away has to be found which is beneficial to all sides. So just like anywhere in life.
Any comparison with https://www.flogo.io/ ?
Might end up difficult to talk about this project. I was pronouncing it "Nathan" till I found the actual name in the docs.
haha, same! I can see it eventually being renamed to Nathan
It would have to be Naaaaathan, then.
haha yes did not invest to much time in naming the project. Had questions about it quite often so added it to the docs very fast ;-)
How is this different from node-red?
Node-Red is more low-level.
You can already see it in the way it describes itself "Flow-based programming for the Internet of Things". So it is "programming" what n8n does not try to be. In Node-Red they give you as a guideline that you should not write high-level nodes if you can write lower-level ones instead (which could build the higher-level one when combined). Which is totally right for programming but not really to allow none coders to automate things. That is also the reason why there are no Asana, Pipedrive, ... nodes in Node-Red. It is simply not what it is made for. It is perfect for IOT applications but not for higher-level automation tasks.
n8n, on the other hand, is probably not the best choice for your IOT application.
So it is simply about using the right tool for the task at hand.
Node-RED targets a different market than this product and Zapier.
Loosely speaking Node-RED has a superset of the functionality this project has, sacrificing customization/generality for simplicity.
Zapier and n8n interface with the user via a catalog model.
Without needing to know what is going on behind the scenes or seeing any code, a person can follow a recipe and bolt together (certain) APIs to achieve business requirements.
The “certain” is an important to note because you will never achieve 100% coverage for your “API glue” for a mid size to large organization “out of the box” with any tool.
That being said, if using a tool like any of the above mentioned as a custom workflow engine (knowing you will be writing software from the onset) or as a solution and not a limiting factor or “silver bullet”, they can be very useful!
Other tools that can achieve similar results (using Directed Acyclic Graphs, where the nodes represent the execution of your code for a desired pre-programmed task) are Airflow, Flink, NiFi, Dagster, Dagobah, Celery, and many more.
Nit: This is not open source - it is source available.(THANK-YOU for being upfront about the license though!)
Still, I might use this, and thanks for releasing
Yes you are correct. Wrote an extra section about it here in the docs: https://docs.n8n.io/#/faq?id=license
Great to hear!
I think it's disingenuous of you to call it "Open Source" and I think the distinction matters to more people than you think it does.
I think "open source (but not really, there's a small restriction)" sums it up better than "source available", so I can understand framing it that way.
OTOH, this is likely to never make it into distro repos anywhere. I also wonder if the author is driving to make a business out of it.
So I'd make three points:
1) It does affect distribution
2) It otherwise doesn't materially affect how I would use it
3) It seems a little like asking for contributions to a proprietary project.
Source Available is pretty sweet if you have a paid product you'd like to do detailed audits on. Especially in regulated environments (finance, medicine, etc).
Many enterprises prefer a paid service, as such contracts usually come with somebody assuming liability for data on the system and being around to resolve problems you'd otherwise need to distract an in-house team with.
I agree. My point is more of "source available" undersells the freedoms it does give you, while "open source" just barely over-represents them, so I can understand framing it as "basically open source".
https://en.wikipedia.org/wiki/Open_source#%22Open%22_versus_...
I fall into the "...conditions in the Open Source Definition..." camp. I think many "source available" projects ride on the coattails of the goodwill associated with the term "Open Source".
You can fall to whatever side you wish, but calling someone disingenuous for siding otherwise does not show much of, indeed, goodwill, nor is it just.
The capitalization of "Open Source" makes it a proper noun or adjective which means it refers to a specific thing. This is why the Open Source Initiative (OSI) always uses "Open Source". You know they are referring to open source as defined by them. "open source" would be referring to the general concept which depending on interpretation could include shared source.
In my view using the proper vs common version of "open source" places this into a disingenuous attempt to be associated with open source as defined by the OSI.
In my view responding immediately with clear clarification of the degree of the code openness, right under the title of the website, places this into this as something which isn't remotely disingenuous. In my view seeing this as disingenuous is, quit frankly, odd.
It is also goes against the site comment's guideline (as well as general sane rule) of: Assume good faith.
I wouldn't pay much attention to such statement knowing the historical background. Stallman was and is a proponent of his own terminology, i.e. "free software", and the related definition which actually isn't that different (hence the catch-all "FLOSS").
Anyway, it's stupid to argue over this. The FAQ on the Commons Clause site itself, reflecting the intention and thinking of the drafter and the initiatiors, specifically states the license is "source-available", not "open source". When talking about open source as a form of licensing as opposed to e.g. software development culture/methodology, the distinction here is quite widely accepted and non-contentious.
Open source does not always mean free. No matter the project you still need to adhere to the license terms even if you have access to the source code.
Most companies will require legal approval anyway before you are allowed to use it.
For instance, at a previous company we were forbidden to use React until Facebook changed over to the MIT license. Facebook had a poison pill buried into their original "open source" license.
That seems pretty fair - avoids the issues of freelance work being done with the project. I find it hard to care about big corporations not having access to monetize it but that begs the question - doesn't this reduce possible hosting solutions? Especially since there's no official hosting. Does this license imply that there can't be 3rd party commercial hosting?
Hmm, how does this license protect you?
https://commonsclause.com/ says that I can sell n8n.io as a commercial SaaS product. So I can create and sell a new Zapier using n8n?
Under Commons Clause you must bring something of "significant value" in addition to the original product. You can't just spin up a new instance.
I guess who/how defines what “significant value” is. For example: for some having it automatically spun up and maintained is significant to them.
If the only thing being offered is the product, but as part of an automated pipeline, from my reading of the license it could go either way, depending on the judge hearing the case.
That wouldn't be a very comfortable legal position.
It wouldn’t be very comfortable for either party, honestly. So I’d have to wonder if anybody small would ever try to enforce it.
I am not an IP lawyer, but I'm not sure that you can monetize this project either the way it's currently set up? Since you're accepting third-party pull requests without requiring a copyright assignment or more permissive license from the contributors, I believe that you'll only be allowed to use their contributions under the Apache-with-commons-clause license they submitted their work under.
Yeah, that seems like a glaring issue. What's the goal of the license? If not to encourage contributions and building other things on top of it, seems more like a "shared source" license. Might make more sense to make at least part of it fully open source, for everyone to contribute to freely (in both directions) and perhaps keep a smaller part (semi) proprietary.
Is this not a controversial topic? As far as I know there are two camps (as is alluded to further downthread) on whether Open Source is literal, or implies more about the license.
I favour the "open source = source available" definition, because that's how most people will understand it anyway. But regardless of where you stand on this, I think it's fair to say it's at least controversial.
I favor the "source available = source available" and "open source = open source (by the commonly understood open source definition)". It's much clearer that way, and wasn't really a muddy issue until certain big software companies started using "open source = source available"
For the sake of clarity you probably shouldn't define what you mean by 'open source' in terms of the 'commonly understood open source definition'.
Oh, that's true - I was sloppy. OSI definition is what I meant.
Having to define "open source" with that addendum illustrates the issue quite apropriately.
"Open Source ≠ open source" is the essence of the problem. The source is open, yet it isn't open source.
Here's an experiment you can run: hold an informal survey amongst a representative subset of programmers. "What does open source mean?". See what they say. I think I met one who knew what the OSI was.
Ironically, "free software" is a similarly terrible term. It should be called "freedom software". I once e-mailed Stallman to ask about it, and he replied they couldn't use that term because it was already trademarked. Welp...
The term "open source" was afaik invented by the people who would form the "open source consortium".
If you're not going by their definition, I think you're just wrong.
Open Source Initiative?
Commons Clause does not meet OSI's definition of "Open Source" nor the GNU/FSF definition of "Free Software" so it's fair to say it should not be called either.
https://opensource.org/osd-annotated
https://www.gnu.org/philosophy/free-sw.en.html
https://en.wikipedia.org/wiki/Source-available_software#Comm...
Yes, I meant the OSI.
Yes, it doesn't fit either definition, so it shouldn't be called either.
The term 'free software' is hard to keep 'pure', because it has an obvious meaning for people who know nothing about software licensing.
But IMO, the terms 'libre software' and 'open source' should not be diluted. It doesn't serve any purpose to mis-use those terms, except confusing everyone.
Prescriptivism is a policy you can choose to follow, but I don't subscribe to it. I'm a descriptivist through and through. And from what I understand, I'm not the only one.
The very language I'm writing this to you in is probably the world's most exemplary instance of this principle in action.
Besides, isn't using things in other ways than they were originally intended the essence of The Hacker? ;)
At the risk of sounding flippant: the pipe operator.
How are you funded? Because this honestly looks quite complete.
I work two days a week for a startup to earn my living and the other time I spend on other projects like n8n. That is why progress is not always as fast as I hope it would be. That is why I also hope to make money with n8n as some point to work full time and make real progress.
Wow how do you do this? Can you divulge the specifics?
Got a donation link? If not, do add it. In the meantime, I will deploy this and test to see how well it works :)
Wow, this is a lot of work. Thanks a lot for open-sourcing it!
Yes it was and still a lot left ;-) But it was worth it as it helps me now every day and will hopefully from now on do the same for other people as well!
Only, it is not open sourced: https://docs.n8n.io/#/faq?id=is-n8n-really-open-source
Deceptive tactics.
Zapier has about 1,000 integrations, more than any of their closest competitors and at a price that is far less than others in their space. What you've done here is great! The UX seems better than Zapier and the extensibility & community approach terrific. The key, though, is going to be adding integrations rapidly. I might also stress:
- Bulk actions. - Sync actions.
And support for other programming languages (eg. python)
Hope that helps.
The value definitely seems to be more in getting the integration. Having the integrations OS would be great to make small changes if needed.
If it's like most things in software (and life), there's probably a long tail of niche/useless integrations in that list.
Not really. The integrations are node-up, meaning the SAAS creates its own integration as value-add to its customers; and there's some user growth that emerges from being in their catalog. But, you point is somewhat valid in that many of the integrations tend to be shallow - so apart from a few key functions it can be tough to use them for complex workflows.
N8n.io looks amazing. I would absolutely switch over to this if there were more integrations! (Namely: Shopify & Zoho Mail)
Half-tempted to dive in and see if I can code something up, but I need to focus on other parts of my business and not dive down the scratch-my-itch dev rabbit hole (again).
Thanks a lot! It would be amazing if you would create those integrations but can understand if you have different priorities. In this case, simply add the integrations you need as a request to the forum. Other people can then upvote them and I know what to work on next. For example, already created a request for a Shopify integration myself a month ago which you could simply upvote: https://community.n8n.io/t/shopify-integration/22
This looks interesting, though Zapier is a little more intuitive interface-wise. Overall though, nice work!
Good god Jan, you are amazing! Liked what you did with "link fish" and "ninja crib" but this takes things to a whole new level. I would love the chance to learn from you!!! Congrats, I'm pretty sure this project will be a big success
Thanks a lot! But probably not the right person to learn from. But that is one of the great things about the internet that you can now really always learn from the best people in their field thanks to Udemy & co.
We're using n8n in production for a month now and are pretty happy with it.
Easily extendable and new integrations can be built easily.
Also helps that the author works here and is generally a great guy ;-)
Same here. Nice work!
Nitpick but the commons clause license isn't really "open source" as much as "source-available"
I love how you licensed it. I'm seeing a trend in how developers are being thoughtful about the licensing and how it will help monetize their efforts later. Excited to see how this goes.
Likely badly - this doesn't meet the OSI open source defintion, and while interesting, many developers are reluctant to contribute to various shared source / source available proprietary core products.
Which I think is quite interesting.
I can totally understand if a person says "I do not want to contribute code to a project for free when somebody else can make money with it". But then they can not contribute code to any OSI approved Open Source licensed project. Because with that license everybody can make money with it. And very often is that somebody the wrong one (like for example Amazon).
The only difference with the Commons Clause is that now still somebody can make money. But that somebody is now the entity behind the project. And they normally put that money right back into the project (by for example hiring developers) and make so sure that it improves and stays around a long time. So I personally would prefer to contribute code to a project which uses the Commons Clause then one which does not.
Thank you for picking the license you did. Developers should be able to earn from their hard work, versus having a Goliath cloud provider take it and profit from it without contributing anything back. No need to cater to potential contributors who have no skin in the game, but turn their nose up at a license they don't believe in.
It's not so much that somebody can make money with it. It's that you, the project maintainer, will be reaping all the monetary benefits for yourself. With open source software theoretically anyone can benefit. If you don't like what the maintainer is doing, you can fork it. In this case, though I believe the commons clause does allow you to fork it, you would still be the one reaping any monetary benefits from the fork.
In my opinion the biggest issue with the commons clause is it no longer makes logical sense to fork the project. If the project dies because you couldn't make any money off it, and you don't go back and relicense your work, the code is practically dead as an 'open source' project. Well, that and that the consulting clause seems to be just sitting there waiting for a major court case to decide what it truly means (even the lawyer who led drafting the clause admitted as such [1]).
[1] https://github.com/fossas/commons-clause/issues/4#issuecomme...
If it dies, there can be a point where the maintainer can re-license under more open terms, no? Until that point, the work and contributions are ensured to help sustain the creator.
I'm planning on releasing my project under similar terms. I'm not particularly interested in community contributions, but rather for there to be trust in ensuring privacy and security. Sometimes, there isn't a one-size-fits-all with the available OSI licenses and I appreciate what op has done to do his best to find what works well for him and the community.
It's less a community in that case than potential customers. Your creating a product, which is fine, but words like 'open source' and 'community' are quite misleading.
The words 'community' and 'customers' are not mutually exclusive and using the word community to refer to your customers is not misleading in the slightest...
I'm not sure sure it will go "badly". I believe there's a fundamental issue with a class of software applications that the current OSI licenses don't do much for. Let me clarify that statement with some examples. If you're a developer of an "open source" library or database engine, you have great OSI licenses available to use. The consumers of your work will either open source their work or purchase a license (i.e. dual-licensing). If, however, you're creating a CMS or some standalone tool (like GIMP, for example), you're left to go down the road of open core (typically). So, the alternative here is to choose a license that's conducive of being able to monetize without depending on donations or support contracts.
I think developers should pick a license that makes sense for them, not necessarily for the benefit of others. What is important though, is that some thought is taken and to try it out. You can always go more permissive later.
I'm working on something that I want to monetize, but the OSI licenses aren't helpful for the kind of application I'm working on. I'm leaning towards a similar licensing structure and have been spending a great deal of time thinking about this and I hope to have more discussions on this very topic as it's extremely helpful for everyone.
edit: typos
I really don't like when people say they are the "x" of "x" or the alternative to "x", doesn't that just drive people to look at "x". Sure it gets the idea across but there are other words to do that. Otherwise, great looking product
It's not always that cut and dry. If X is already well known, it actually has the opposite effect -- it capitalizes off of X's brand and familiarity and drives people to the new product. It's a common technique (that is frequently misused) in marketing and advertising.
I don't know if X=Zapier here is that effective, but I recognized it right away, and clicked the link to learn more.
This really looks like a great software and seems that the guy behind it knows what his doing. Additionally being open and fair about the licence. I will try it ASAP and wish the project gets BIG.
How do you compare to StackStorm ? You mentioned other similar solutions as less adequate, but I'm curious to get a quick comparison.
This would be a nice addition to the website, comparing the solution with each of its competitors.
Look awesome, and although the license is definitely NOT open source (although you DO say the parts that people care the most are best-effort open source to the community), this has the potential to motivate other people to work on similar projects or suggest improvements to yours.
However... The beauty of Zapier relies on its amount of pluggable blocks. I don't think there's anyone in this market that has as many operations as Zapier and using custom blocks you can do pretty much anything. Yes I am totally a fan of Zapier as I have been using it for years! Zapier is like LEGO, there are many clones of LEGO but only one true LEGO (ouch my feet hurt just by thinking about it ;) ) I really hope you can get people to contribute more and more integrations as that's what really matters at the end of the day: The ability to use little or no-code to achieve automation between various platforms!
Zapier is propietary and prohibitively expensive. Yes, I like it -- but I'd rather support small projects like this one, even if it requires a bit more of time.
Super happy to see this effort and eager to check the code out soon!
As someone who relies on a lot of Zapier-style API connections, I’d love to hear more about how people approach it - how you go about managing env vars (keys/token), abstracting similar service procedures (oauth, webhooks) and generally monitoring 3rd party API endpoints for keeping the connections healthy? Any advice from Zapier / IFTTT veterans?
Edit: the n8n docs seem good and also address most of my questions [1]
[1] https://docs.n8n.io/#/nodes
Yes, any advice would also be very appreciated from my side.
Great to hear that the docs are helpful! They were actually the main reason why I did not launch on Product Hunt/Hackernews earlier. It was very important for me to have something in place which is at least reasonable. Nothing more annoying than bad docs. Anyway, still a lot on my list to add documentation for. But it will get better, I promise!
Cool project. One aspect of these integration systems is that the volume and velocity of integration development is one of the main ways they show value. Zapier claims 1500+ integrations, and they have many competitor with similar counts of integrations. Somehow, they always seem to not have that thing I need.
I wonder why, in this era of Swagger / OpenAPI / Postman Collections / API Gateways ... why this is so difficult? I feel like there was a promise that integration would become more magical at a rapid clip, but as it stands it just seems like there are more options but no less headaches.
A lot of APIs don’t support the tooling you mentioned, have all sorts of rough edges (return improper http codes, or don't return them at all), or act...quirky at scale (based on my experience at an automation workflow org).
Of course, as APIs improve (OpenAPI, etc), the barrier to entry for all workflow tools declines (which is a good thing!). You're then just serializing and deserializing JSON (or a mutation thereof) between two or more steps. Just as Google makes their Terraform provider a first class citizen by autogenerating the Terraform provider based off of their APIs (Hashiconf 2018 SF talk), so could integration partners for workflow automators. Just takes time for the ecosystem to mature.
Does Datafire meet some of your requirements?
https://github.com/DataFire/DataFire
I've used it before and it's not too bad.
Thanks for sharing, that is definitely compelling. I like that their integrations cover lots of API methods, whereas a lot of simpler services only cover a few.
Sorry unsure, but perhaps this is similar?
https://stdlib.com
Open source or not (I'm so confused) this works really well. Solid job.
From other comments in this thread, it's apparent this is "source-available" but not "open source" in the sense of a free software [0] or OSI-compatible [1] license.
But the usual benefits of free software, like what has been possible with the Linux kernel, GNU software, and so much more, are not going to be possible to the same degree with this software.
[0] https://www.gnu.org/philosophy/free-sw.en.html [1] https://opensource.org/osd-annotated
Thanks for this! I was just yesterday looking for good workflow automation tools, and was leaning towards Huginn, but I will definitely check this out.
Great to hear! If you have any problems simply post them in the forum I try to get back to you asap (sorry, will maybe be right ow longer than normal as I have a lot to follow up right now).
Crowded space, but darn few (if any) shared source or community based solutions. Here's a several examples from a market study I did in 2018: Workato, Apiant, Inegromat, Snaplogic, CloudHQ, Boomi, Tibco, Jitterbit, AWS Lambda, Mulesoft, Tray.io, ApacheNiFi, Stringify, Adeptia, Kotive, Cazoomi, Scribesoft and several more.
I really think the community angle is unique.
I work at Boomi, on their Flow product (similar to this project), and we open source everything in our product, except for our core workflow engine - https://github.com/manywho (our pre-acquisition name if you're wondering).
The community part is hard to generate though... there's a lot of enterprise in the workflow space.
StandardLib also has a community, though not sure how big it may be.
Pricing is a key differentiator. My market research included a pricing analysis and Boomi was priced well above Zapier and other similar solutions.
I think there is a LOT of money ceded to less expensive offerings by 10 or 15 providers (including Boomi) all chasing the same enterprise market. I would've expected tiered pricing to emerge to a greater extent, but haven't seen it.
I watch this space very closely.
Thank you for sharing this list.
It’s maybe a dumb question but even after looking in some of them I usually fall back on a classic cron job + some Python scripts for automation for the flexibility. What’s the biggest advantage of these services / solutions when you already have some servers available?
Ability for a non-technical user to implement and manage the automation.
You don't have to learn several APIs to do any integration
Which one in your opinion allows for extensions of those APIs the best at a SMB price point? My frustration with Zapier is that I if they don't support the trigger, I'm kinda sol. I wanna be able to say "I want to manually add this API call" in a low code environment.
Also - do you mind if I grab some of your time to discuss on the phone? my contact details are in my profile.
Thanks!
Is your market study available to read anywhere?
Feel free to email me for it. My contact info in my profile (soon)
Any chance it's still available?
Do I understand this correctly?
- I'm allowed to setup an instance and charge clients to use it.
- I'm NOT allowed to host the instance for clients and charge for that hosting.
question: if I have a project management software saas, and I want to integrate n8n to make automations (for example: when a task is marked as completed), is the license valid for this use?
Also interested in this example and the answer.
Hope this question is answered.
Can someone possibly summarize why this doesn't fit the strict definition of open source? What important rights are missing?
You can't place prohibitions on selling the software or consulting services related to it. The definition of open source is here:
https://opensource.org/osd
I'm one of the people who subscribes to the Open Source Initiative's definition[1] of the term "Open Source". On that basis, the "Commons Clause" applied to the license of this software discriminates against fields of endeavor. This makes it a "source available" license to me, and not an "Open Source" license.
[1] https://opensource.org/osd
technical note: USD uses commas to denote thousands. So, in USD 30.000 == $30 which isn't worth the time spent to do the research to pick up the first phone call.
Social note: in many US cities $30k isn't enough to survive. In the US it's certainly not enough to live _well_. So, you're basically saying "Hey, I give you permission to make an important contribution to the success and community of this project as long as you're willing to take an absolutely CRAP salary for it."
that's.... not really cool.
I don't think it should matter how much a support person can make supporting your project. The only way a support person will be crazy successful financially is if your tool is ALSO crazy successful. It's a mutually beneficial situation. Don't limit them. Their success is your success.
If you are running a consulting/support business and have your customer download the software then this clause is likely not even enforceable. You would not be distributing or running the software and therefore would not be subject to the terms of the license.
I guess so yes. At the same time, if someone installs and helps their customers with n8n, in addition to some other bigger more "main" things s/he does, then $30k can be fairly much?
If it's not the contractor's main thing but a smaller part of his/her offerings? ... O.t.o.h. maybe s/he never gets really good at n8n if s/he won't focus on it full time.
Sorry for the confusion. The 30k was just some random amount to make it easy for most people. And did honestly not expect that a lot of people's income would come to 100% from n8n. Thought it would be one of multiple things they do and so 30k seemed like more than enough to cover the majority. Additionally did I not mean that they can ever make more. I simply wrote that up to that amount they do not even have to say anything. In the next sentence it additionally says: "If you have bigger things planned simply write an email to license@n8n.io."
This is very reasonable, and great that you provided those clear guidelines! Too bad the poster above didn't provide the full quote. Great project!
If you think of $30k as the cap of the "free tier" it seems more generous.
HN usually finds a theme to complain about with any cool project. Looks like this time they picked licensing. Just wanted to say thank you for making this project. I think tech like Zapier/IFTTT are really cool, but I would never trust a closed platform of this sort.
But something like n8n I would consider using, because you've provided an escape hatch to lock-in by making the source available. I think it's totally reasonable to prevent other companies from profiting from your work. I also think it falls under the umbrella of "open source". If someone wants a truly FLOSS version of this, they're welcome to make it themselves. But they won't, they'll just complain and keep using n8n, because the licensing is good enough for 99.9% of use cases.
EDIT: I just want to point out that there's been some discussion of licensing here which I've personally found interesting and instructive. I've seen several people suggest that there is a definition of the term "open source" that is essentially universally agreed upon (that being the Open Source Initiative definition [0]), and that that is the only valid definition. I've worked in what I consider to be open source for many years, and wasn't aware that such consensus had been reached. My personal views have not changed as of yet, but my paradigm has definitely shifted. I intend to pay closer attention to how others use this term, and carefully attempt to be clear about my usage in the future. Having a single agree-upon definition of things is always valuable, and if that's where we're at I'm all for it. I'm just not convinced yet that it's actually 100% agreed upon.
That said, I think the author of n8n was pretty dang clear.
[0] https://opensource.org/
There's a weird trend on HN. For proprietary products (e.g. slack) I rarely see them getting criticized for having a proprietary license. If you are fully open source, then of course they love you. But if you try to strike a compromise and give away a lot while still keeping some licensing terms to let you make money off your creation, then you'll be bombarded by complaints about your licensing.
If Microsoft started calling Windows open source, I would be pretty peeved too. The word open source here is used as a marketing term for a product that isn't in spirit or reality. Yes, the source is available; that's nice, but it's not the same.
Windows isn't free. Nor is the source available to be viewed, modified, extended, learned from, etc. Also, you're comparing one of the biggest tech companies in the world, to an individual who is trying to make a living. This is an unfair characterization on every level.
I mean, I'm just using a popular non-open source piece of software as an example, you don't really have to read into it this much. Every comparison has limits, this isn't any exception. You can substitute 'Windows' for 'Gitlab EE' which is also proprietary software with available source code.
The depth of someone's pockets doesn't influence the definition of open source, though. This is not a characterization at all, rather, I'm saying that using the word open source to describe software that doesn't meet the criteria is always going to upset people. There is a simple solution that costs no money: removing the word open source. It is even recommended by the folks who push common clause.[1]
I realize people are very passionate about this, but please try not to read into what I'm saying too deeply.
(Also very notably: I have absolutely NOTHING against proprietary or shared source software, or developers making money; love Gitlab EE as an example. Just please be honest.)
[1]: https://commonsclause.com/
Well...characterizing the usage as a marketing term wouldn't be relevant if the potential for making money weren't an issue here.
Even beyond that, on a human level, the attacks on an individual trying to make a living seem unnecessarily harsh. My critique is mostly about the spirit of the negative comments (not just yours, sorry), which all seem to assume malice where there likely is none. I.e. several comments here and on the github repo calling the developer a liar and coward, etc (again, not you, this just happened to be the comment I replied to)
And I think this entire discussion proves that the definition of 'open source' is not as cut and dry as some people would like. And because of that, saying 'just be honest' when someone uses one of the alternative definitions of the term seems unfair.
I've always thought that the terms FOSS exists specifically to provide some extra clarity in this regard...
And I don't know what you'd call this other than "open source" because I haven't heard the term "source available" until today, and I would have had no idea what it meant if that's what the developer had used....
There is nothing wrong with marketing a project, be it open source, proprietary, free, non-free, etc. I never suggested that. Just about everything is 'marketed' in some sense.
It's because there's a lot of passion involved. Even people who are pretty great open source developers have acted in a way that is perhaps not so noble if you read the flagged comments.
However, I don't think this is necessarily out of assumption of malice. The problem is, it doesn't matter if the author is malicious or not. The term 'open source' carries some connotations that many people have an intuitive understanding of today. I firmly believe the very reason a lot of big projects choose open source is for the marketing benefit, and imo it is not deserved if your project isn't really open source. This could seriously harm the reputation of something that took decades to build, and if that seems alarmist, well, I know I'm not alone in this sentiment.
The thing is, if I say something is 'open source,' you almost certainly, today, will understand that to mean what it has meant for decades: the OSI definition of open source, contrary to the wishes of some (including rms, for example.) This is just the layperson's understanding. They may not have a deep understanding of licenses or permissiveness, but it comes with a sense of what a project has to offer. Being able to profit off of open source is something that people inherently understand nowadays, and it took a long time for that to happen.
The reason you wouldn't have understood another term is because there is not a common understanding for 'source available' or 'commons clause.' This is because it was not very popular in recent years, and remains relatively unpopular. It is mostly pushed by companies that built amazing open source projects and had trouble with creating a sustainable business around it.
And therein lies the contention.
- Because of what Open Source implies, it gives projects a decent marketing boost - including, of course, the common case where they are truly open source. People rely on open source projects understanding the implications and knowing roughly what they can do with it.
- Commons clause doesn't imply the same things. But some companies are trying to use the term 'open source' to describe them anyways. To me, this looks a lot like trying to have cake and eat it too. It's not the same 'open source' that people have slowly grown to understand.
Of course most people won't understand why this issue has much contention, because this type of thing seems like a minor detail. In fact, many people, including me, initially found it confusing that licenses like GPL allow you to profit off the work so as long as you follow the other clauses. It took me a long time to understand that this is a very important part of what makes open source special: the disconnect from the profit model. If you reconnect the development and licensing to the profit model, in my mind this is losing a key part of what makes open source so damn effective. Having many stakeholders that all profit from a project can be incredible - the Linux kernel being one such example.
People have to make money, though, and so going through the risky proposition of making truly open source software and trying to build a business around it is not always appealing. In my opinion, the obvious choice is to not make open source software. So-called "commons clause" is one option. But again, I think there is real danger in "open source" being conflated with things that nobody understands it to be.
Fair points. And it gives me a little more context into the intensity of the reactions. Thank you.
I don't think it's particularly weird, it's about misrepresentation. Most users attracted to open source licensing aren't aiming for abstract goals like "give away a lot" or even "give away as much as possible", they're aiming for "give away practically everything so they can use it for free in any way they want". Proprietary products don't waste these users time as they are clearly not suitable, but advertising an open core product as open source will attract a lot of unsuitable users who desire open source when you're offering open core.
If you're trying to make money, just don't do open source. No one owes you kudos for striking a compromise no one wants.
In terms of the licensing debate... Did you bother to actually read the Common Clause FAQ? Here are the first 2 FAQ entries:
"What is Commons Clause? The Commons Clause is a license condition drafted by Heather Meeker that applies a narrow, minimal-form commercial restriction on top of an existing open source license to transition the project to a source-availability licensing scheme. The combined text replaces the existing license, allowing all permissions of the original license to remain except the ability to "Sell" the software as defined in the text.
This Clause is not intended to replace licenses of existing open source projects in general, but to be used by specific projects to satisfy urgent business or legal requirements without resorting to fully "closing source".
Is this “Open Source”? No.
“Open source”, has a specific definition that was written years ago and is stewarded by the Open Source Initiative, which approves Open Source licenses. Applying the Commons Clause to an open source project will mean the source code is available, and meets many of the elements of the Open Source Definition, such as free access to source code, freedom to modify, and freedom to re-distribute, but not all of them. So to avoid confusion, it is best not to call Commons Clause software “open source.” "
This is really neat! I'm generally prohibited from using stuff like Zapier at work, since we handle a lot of client data and passing it through any third party opens up a Pandora's Box of legal reviews. The self-hosted nature of this would bypass a lot of that hassle.
Public Service Announcement for anyone at BigCorp: Microsoft has it's own tool in this space called Microsoft Flow[1]. It's not as feature-filled as Zapier, but it works in a pinch and you get access to it automatically as part of an Office/Microsoft 365 license. So unless your corporate IT has gone to great lengths to explicitly disable access to it, you can leverage it to make your life at least a bit easier.
[1] https://flow.microsoft.com/en-us/
Have you thought about teaming up with an ESB like https://zato.io/ ? Could really help both of you, I think.
Looks awesome!! Bookmarked, planning to play w/ this. Kudos for launching something useful. :)
This reminds me a lot of a visual code based data processing tool developed out of the NSA. Apache NiFi. The difficulty with all these low/no code environments is getting scale and maintaining enough widget blocks for it to be productive quickly.
What are your thoughts on StdLib.com?
I've seen enough of these supposedly non-programmer-friendly interfaces to judge them all guilty until proven innocent (not that many, to be honest, but I am scarred nonetheless). Looking at the video, it's not the worst I've seen. But please, I beg you (the authors here or anyone building a similar product):
- Provide first class debugging and dry-run support. Don't make people either run in prod (as the demo video effectively does) or set up full testing environments.
- Strict, comprehensible scoping rules. Non-programmers will have more, not less trouble with having named data propagated everywhere for reasons that aren't visually clear. Global state is still bad.
- Don't make users think about JSON.
- Supply auto-layout. Don't force users to manually reposition things to get a decent layout, and ideally don't let them. The demo video seems to show at least the first half in place, so that's good.
- Version control. Possibly via...
- Ideally an isomorphically editable text representation. You can switch between graphical and text representations and have changes propagate.
Maybe this project checks more of these boxes than I've seen so far. I'm pathologically optimistic, so there's a good chance I'll work with this enough to find out.
I don't really know why everyone wants to keep making these benighted flow-chart UIs instead of using the relatively proven Scratch UI model.
I'm curious - could you explain what you mean by the "Scratch UI"? I did some searching on Google, but there appear to be several products which use this term.
Is this what you meant? https://scratch.mit.edu/developers
I believe they are talking about that. I've seen that methodology of UI take off lately, too.
Exactly that, yes.
Leaving the UI aside, how is this different from Huginn? I have a few Huginn agents running menial tasks, but I find time consuming to debug issues. Does N8n have more connectors? What are the strengths compared with Huginn?