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.
Here's a concrete example of the connotation in action: I wouldn't have clicked thru to the comments or the project's site if the title of this posting was "Source-Available Alternative for Zapier".
I saw "Open Source" and assumed, as I suspect many people did, that it was talking about the Open Source Initiative definition of Open Source. Intended or not, those two words carry a connotation for a lot of people. I'd rather not see that connotation watered-down, either.
Then only click on links that say "Free Software". OSI redefined "Open Source" post-facto, and it has always been somewhat ambiguous. Free Software has always been unambiguously "Free as in Freedom Software".
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?
207 comments
[ 354 ms ] story [ 1648 ms ] threadn8n 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!]
Interesting resource. But, how do you filter for just self-hosted... I can't find that as a specific category.
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.
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.
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.
Disclaimer: Worked at a SaaS company, now work in highly regulated financial services.
The source and documentation for setting it up, using it, and developing with it are already available.
Look at the Business Source license — they do that. (I'm doing the same with my project: AGPL —> GPL some years later.)
Best wishes :- )
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.
Commons Clause is not Open Source. It is free-of-charge (for certain uses) source-available proprietary software.
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!
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.
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.
Still, I might use this, and thanks for releasing
Great to hear!
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.
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.
https://en.wikipedia.org/wiki/Open_source#%22Open%22_versus_...
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.
It is also goes against the site comment's guideline (as well as general sane rule) of: Assume good faith.
I saw "Open Source" and assumed, as I suspect many people did, that it was talking about the Open Source Initiative definition of Open Source. Intended or not, those two words carry a connotation for a lot of people. I'd rather not see that connotation watered-down, either.
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.
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?
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?
That wouldn't be a very comfortable legal position.
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.
"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...
If you're not going by their definition, I think you're just wrong.
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, 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.
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? ;)
Deceptive tactics.
- Bulk actions. - Sync actions.
And support for other programming languages (eg. python)
Hope that helps.
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).
Easily extendable and new integrations can be built easily.
Also helps that the author works here and is generally a great guy ;-)
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.
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...
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.
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 don't know if X=Zapier here is that effective, but I recognized it right away, and clicked the link to learn more.
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!
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
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!
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.
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.
https://github.com/DataFire/DataFire
I've used it before and it's not too bad.
https://stdlib.com
> Standard Library: APIs as Building Blocks
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
I really think the community angle is unique.
The community part is hard to generate though... there's a lot of enterprise in the workflow space.
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.
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?
Also - do you mind if I grab some of your time to discuss on the phone? my contact details are in my profile.
Thanks!
- 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.