When I started n8n, I worked on it part-time for around 1.5 years. I believed in it and got more and more excited. But it was also very stressful, and the progress was slow. The reason was that n8n was only a side-project, I had another startup and a part-time job. But in time, it became evident that I wanted to work on n8n full-time or at least have a clear path to get there.
Table of contents
The problem with open source
Choosing the right license for n8n
What is even “open source”?
The beginning of fair-code
The advantages of fair-code
The future for fair-code
The problem with open source
I knew that if I open-source n8n, someone would come along and offer a hosted service on top of it. They would be much faster and better at doing that than I could be, as they could concentrate only on the hosting aspect and not the core code. They would charge money for it and I would end up supporting their users, fixing bugs, and adding features––that, too, for free. In a situation like this, I would not only compete with my product, but also always be at a disadvantage because of that.
Seeing this scenario, I was sure that open-sourcing the project was neither in mine nor the users' interest. The people behind the project are the ones that push it forward. They are the ones that contribute back the money they make to the project. For external companies, this is normally not the case.
So I looked for a solution to address these issues with open source. I could have gone open-core, but honestly, I never liked it. After all, it means that I have to make the product artificially worse to make money. This would have degraded the quality of the product, and it seemed like a horrible idea. I wanted the project to be successful and get adopted by a broader audience. Hence, I couldn't afford to open-core the project.
Choosing the right license for n8n
When I was searching for a solution, I found out about the Commons Clause (CC). The Commons Clause allows you to restrict how the projects are commercialized and it was exactly what I was looking for. Everyone can use the project for free, but if you make money, you have to pay. So I chose the Apache License version 2 with Common Clause as a license, which means that n8n was not an OSI-approved open-source project.
When I launched n8n, I called it “open-source” (note the quotation marks), and everywhere I mentioned that it uses Apache License version 2 with Common Clause, to make it clear. Additionally, I added a section in the FAQ to explain that.
The reason why I called n8n open-source was simple: the source code is open, it can be forked and used for free by everybody, no matter if it is used by an individual or a company with 10,000 employees. The only difference is that they could not charge money for it. As there was no other term to describe this model, I felt it was the correct and least confusing thing to do. I thought that for 99% of the people it would not make a difference anyway.
What is even “open source”?
That is where the problems started. Once I launched n8n on Product Hunt, somebody shared it on Hacker News. People started saying that I am lying, misleading them, and wasting their time. One person also said that I am gaslighting people. In short, I am a horrible person. It got so bad that Hacker News stepped in. But instead of banning the person who misbehaved, interestingly, Hacker News changed the title of the post. The title was changed from something like "n8n.io – Open source Zapier alternative" to "n8n.io – Workflow automation alternative to Zapier".
This was, in my eyes, even more misleading. It made n8n sound like a closed-source SaaS product. But neither the source code was closed nor did I have a SaaS offering. They could have at least used the words like "self-hostable" or "source-available". I am especially not a big fan of the last term, but literally, anything would have been better.
The person that said I was gaslighting people also opened a GitHub issue with that exact title. It got over 330 comments. (If you are ever bored, that issue is an interesting read!) In that issue, people demanded that I remove all "open-source" mentions and replace them with "source available". But most people just never heard of that term, and even if they would have, it would be totally meaningless, as it literally means "source available". It describes a proprietary project where the source code is available, but can not be used and an MIT licensed one as well.
This kind of felt like it defeated the purpose. Why would I use a term that does not have a helpful meaning at all? For that reason, I was quite reluctant to use it, especially because of the way these people "asked".
Even lawyers were writing to me saying that calling the project open-source is legally correct, but I am not allowed to call it "OSI-approved open-source"––which I didn’t. That was obviously great to hear, but it didn’t help to de-escalate the issue.
Even the president of OSI reached out and we discussed possible solutions. I proposed a level system to him. So, “open-source” without a level would be the current definition, “open-source L2” could add commercial restrictions, and so on. Even though he was very nice, and we had an interesting conversation, he sadly did not warm up to my idea. He could also not have decided it by himself anyway. I just hoped that he would back me up when I proposed this level system.
The beginning of fair-code
So I had to find an alternative. I didn't want to give up. I didn't want other people to go through the same situation that I did. After all, this seemed to repeat itself time and again. That is when the idea of fair-code was born––to give people an alternative term to use. The idea behind it was nothing new, but it is essential to have a term for it. Only then do people know what to expect, what is allowed, and NOT allowed.
Kenneth Malac, who was a part of the GitHub discussion, reached out via email. He had thought about an alternative to the problem as well. So when I was in San Francisco in early 2020, I met with him and we realized that our ideas generally align. Over the next few weeks, we formulated the definition of fair-code and launched the website.
Once it was ready, I changed the wording on the n8n website. n8n become the first official fair-code project. But even after the switch, there were discussions about me using the words "free" and "open". People said that it is still misleading and should be changed. I guess the discussion around open-source and fair-code will be ongoing.
Fair-code means a project is generally free to use, and anybody can distribute it. It has its source code openly available, can be extended by anybody in public and private communities, and, most importantly, it is restricted commercially by its authors.
In short, anyone can use the code for free but if one wants to make money with it, one has to pay.
The advantages of fair-code
For project maintainers that choose fair-code, the main advantage is clear: fair-code increases the chance of making the project long term financially viable.
Fair-code increases the chance of making the project long term financially viable.
Fair-code also has advantages for users. They all can use the project totally for free, similar to any open-source project. Additionally, they know that the company or person behind it is financially healthy, which means that it will probably stay around for a long time. It also means that people can get hired to fix bugs, create new features, create documentation, and answer questions in the forum. All of that without the need of taking away important features.
Even OSI-approved open-source projects have a win from this, because fair-code projects have better financial stability than their open-source siblings and can thus help them financially. After all, it is in the interest of the fair-code projects that their dependencies are correctly maintained.
Companies that want to integrate fair-code projects into their paid offerings have to get a special license. Now they are forced to pay, but the money goes directly back into the project––a project they depend on. So the money is not lost; it is used to make the project better, which in turn improves their offering.
For these reasons, in my eyes, everybody wins from fair-code projects.
The future for fair-code
I proposed a level-system to OSI earlier. A level system, similar to what I proposed, should be implemented. The most important thing is to get more projects to adopt it and generally get fair-code better known. Because unless people know what it means, users will be hesitant to use fair-code projects, and maintainers will be unwilling to adopt it.
So if I can ask for a single thing from you, it would be to please spread the word about fair-code!