Jan Oberhauser:
There's open source and there's source available. The problem was that there is no good term out there to describe what we were.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. Welcome everyone, we're excited to have N8N on the show today. And specifically Jan Oberhauser, who's one of their creators and founders of the project. Jan, thanks for joining the show.

Jan Oberhauser:
Thanks for inviting me. Happy to be here.

Eric Anderson:
Jan, I have to give you a little plug here that you've got an impressive project on your hands, 30,000 plus GitHub stars, 55,000 plus community members. There's a lot of love for what N8N is doing. How do you describe N8N to people? What is it in a couple lines?

Jan Oberhauser:
In the past we described ourselves as an extendable workflow automation tool, so really it allows you to connect everything to everything more or less. When we are fair code licensed, which is very important to mention again, like we are not also approved open source. But the end we are really a workflow automation tool for technical people.

Eric Anderson:
Super. So workflow automation for technical people, although most people aren't writing code as much as they are low code, drag and drop experience.

Jan Oberhauser:
That's correct, yeah.

Eric Anderson:
And how did you get into this? Maybe you could quickly tell us about your background and what led you to feel like there was a need for something like N8N.

Jan Oberhauser:
Sure, yeah. My background actually, I worked very many years in the movie industry. I did effects for movies, which is called compositing, meaning it was my job to combine the computer generated images with the actual filmed images. So we moved the blue screen, green screen and fire, rain or whatever was important for the scene. I did that a few years and at some point I switched roles, I became a pipeline TD. Meaning it became my job to make the life of the artist more efficient, easier, which obviously involved a lot of automation. And the problem I saw there is that we had this very well paid people, very smart people that literally they won the Oscar for Benjamin Button the year before and they always had to come to me for the most simple things. "Hey, can you please help me to automate this? Can I do that?"
Obviously there were two answers, I could say yes or no. And the worst case scenario obviously said no, which was very bad because they had to do this thing forever and it was normally the most fun things to do. So it was bad for the people because they could have had more joy in their jobs and it was also bad for the company because these people could have added much more value in different ways. Always in the best case scenario, I said yes, but it was still very bad because I was there I realized that because I didn't have the problem, they had to come to me and had to explain it to me and then I created something. Then it was obviously not exactly what they wanted so I went back again, created something new and reiterated for a while. And I always felt like the people that have the problem, they should be able to help themselves because it didn't even end at a creation process, it was going on forever.
For every small change that they come back to me, "Hey, now send it email, not to John, send it to Jim." And then I had to go in there, change the code, committed to deploy it again, it was very inefficient. That kind of stuck with me and at some point then I left the movie industry and I started an own startup. And there I saw something very similar, but even though I always could help myself because I could program and could do the things. I realized that even the most simple things, for example, we have a workflow, every time we receive a GitHub star, we get a message in Slack, that's very simple to explain. It's also very complex a program, but if you do it it's still going to take you half a day or multiple days because you have to research the APIs, you have to write the boilerplate code, find a server, upload it, make sure it doesn't crash and all of that stuff that literally nobody loves to do.
And the worst part is that actually tens of million of people have done that before, get something from GitHub, send something to Slack. Actually that has been done millions of times, the only thing that's different is the middle part. So it felt wrong that I had to do something again that so many people did before me. So I wanted to create something where you just have to worry more about the logic in between and then just use building blocks to do the more boring part of that. And so I'm just looked in the market, researched a few different tools, but all of them had different issues. So I then just brainstormed for a while and thought how should a product work but then wasn't [inaudible 00:05:01] helps myself with more technical but also enables this less technical people to help themselves? And then instead, what ended then came out of, it's probably start in the beginning of 2018. I programmed for roughly one and a half years in my free time because I worked on this other startup as I mentioned before.
I also worked at a second startup to earn some money because yeah, I have five in children and I can talk about a vision all day long but they still want to eat. So it took a little bit longer and then in June 2019 I uploaded to GitHub. So then wanted to see what people like, they like it, what they think about the project. But it wasn't ready for prime time yet, I didn't have proper documentation, didn't have a form I think at that time. And it was still very early, so I really just wanted to see and the people that found it helped me. They gave me feedback, help with the documentation. Then I wrote a lot more documentation and then in October 2019, I did the proper launch on product under Hacker News and that really took off.

Eric Anderson:
Wow, so there was a time when then you believed this and it wasn't clear the rest of the world was going to get excited about it, but it clearly has.

Jan Oberhauser:
Yeah, I think it's the same with every project, we just hear about it once it worked.

Eric Anderson:
And it sounds like it was mostly you from the beginning. Were there other early people you had to bring on board and kind of convince them of the vision?

Jan Oberhauser:
No, in the beginning till I launched it was just myself. On the day I launched, actually there's one contributor started from the US. He opened the PR and did an integration, he gave feedback. He opened another PR with another integration at some point. His name is Ricardo, he created six integrations for N8N just for fun in his free time, it was really amazing. And he really became then the first hired person as a freelancer and now later he became a full-time employee. And he's the only person right now we have from the US because obviously such people he have to hire and he's just great. And he just came by himself because he liked what we were doing back then, what I was doing and yeah. We've got a few more other great people like that that just came out of the community and it's always nice if people come by themselves, understand their product, understand their vision and their just want to join.

Eric Anderson:
I love that. I always tell people that it's fairly easy to get noticed in an open source community if you just put in a little bit of, it's not even a ton of work, and that always seems to pay off.

Jan Oberhauser:
I think especially and even in these people, it's like you just have a PR, you let it sit there for months, you don't interact at all or you just close it. That doesn't work but if you really work there, give feedback, show gratitudes and I think that that really helps a lot. It's the same not just for contributors, it's the same for people in the community. It's just showing people how helpful they are and how great it is what they're doing. Is because the most people are used to go on a forum, ask a question and they leave. But it's really getting those people from just asking also to contribute back and giving them a great experience. I think that really makes all the difference that they actually switch from just being there to get help to also giving help to others. And I think that's what worked in our community amazingly well. We have so many great community members, they're helping others out all the time for free just because they had a great experience in the past, would like to help other people.

Eric Anderson:
Say more about the community, I mentioned to you this before the show, that was something that I was really struck with. You've got a large community, they seem fairly engaged. Maybe if you were to advise another open source founder, what are the tools you're using? I know there's a debate between Discord, Slack and forums. Do you have people that are assigned to engage in the community?

Jan Oberhauser:
Yeah, actually one of the better decisions I made very early on is not to have any sync communication, so there was no Slack channel or a Discord. Because obviously I found an automation company and efficiency is quite important for me. And I realized very early on that I cannot build a project and at the same time answer the same question a million times because people always have the same issues again. And obviously some you can obviously say, "Hey, if people have the same issues, you probably should fix the product." But as a one man show that's actually was not that easy. So I thought okay, I want to be efficient so I create a forum where people can ask questions, I help them, I answered one time. The same question comes up again, either they find themselves or I can link it. That worked out very well because it really allowed back then when I was myself just to handle that and again, then when this first contributor joined Ricardo, he jumped on there and helped all the other people out.
That again, that spoiled the next generation of people. I think that is really something I can recommend for everybody is that just free up a lot of time, helped to build a great community. And again, the time you could invest in the product or on other things, it actually mattered rather than again, answering the same question a million times. I think that this was definitely one thing that worked out really well and I think just caring. For example, very early on after I launched, I got a lot of emails from investors that they were reaching out. But in the end either I didn't answer at all or I waited a while because there was so many people starting to use N8N, which was much more important for me than talking with investors at that point. I think just prioritizing the community accordingly is just really important if you want to build a great community.

Eric Anderson:
Agreed. Good. And going back to what N8N is and at the beginning of the show we were trying to talk about the categories of software and where N8N fits. And we just talked about how there are other kind of code based workflow solutions like Temporal and Conductor, which we've had on the show. And then we talked about more, Windmill maybe as well and then maybe more graphical ones. I didn't have any good examples, I think people talk about Zapier, I don't know Jan if that's a good fit. Maybe would you characterize the type of software N8N is?

Jan Oberhauser:
I think the most people think about Zapier and see the first time N8N, and actually to honest when I launched, I called it a Zapier alternative because it was the most widely used tool, most widely known tool. It made definite sense at that point in time. But in the end, we actually don't compete with Zapier that much because the difference is that Zapier is an amazing tool if you want to do more simple things. You want to connect A to B, you have something that takes two to five steps, I think Zapier is great. And if you're not technical and that's all you need, Zapier is the tool for you. Where really N8N shines, is when you have more complex things to do. Because if you have for example [inaudible 00:12:14] A, B to C, you have A to B and then depending on the data you do C or D. And depending on that you do something else and at some point it goes together, it branches off, it can merge data back together.
This really complex use cases where something like Zapier doesn't work. That's what I would generally say, that's where N8N gets interesting. And I think especially what people like about N8N is the next to the flexibility is you don't hit this kind of glass ceilings. The problem with the most NOCO tools is like you build and build and build like, Hey, I just spend a week on it and I'm already done, it would've taken me months to do it. I just need this little bit more and I'm done this tomorrow probably. Didn't realize, okay, actually this one thing that I want to do now and the tool hasn't been created for that. And then you hit this glass ceiling and then it actually becomes very painful, then you have to invest, you actually pay back everything you saved twice to make that one thing work again.
That is what people really value about N8N, you can always fall back to code, you have a code note where you can literally do anything. You can write your own notes, every note and it's like an integration. It's like a note in the note graph, it's a note JS code so you can literally write anything you want. And yeah, you don't hit the ceilings, you always stay flexible. You can also self-host a product which is great for data security and data privacy. But I think it's the flexibility really that comes out the most. Is like that, they just know that there are no limits with N8N, and that really resonates very well with our user base.

Eric Anderson:
And your users are technical users, I think I heard you say.

Jan Oberhauser:
Exactly, yeah. We just drive ourselves as a workflow automation tool for technical people

Eric Anderson:
Maybe what are the use cases? So are there things that people keep coming back to N8N for?

Jan Oberhauser:
Yes, that's actually, it's kind of a good and a bad thing about a product like ours. I always compare with Excel, like people use Excel privately in niche corporations. They do vacation planning privately and in niche corporation, I don't know, they plan the different shifts. And why does it work? Because Excel is this very generic tool that doesn't care about what's in it, it's really just some data. And N8N is very similar to that. It's like you have trigger notes that kind of start the workflow with some initial data and then each note can use the data for an action or it can transform the data, and it doesn't care about what data it is. So right now we have on the one hand side people using N8N privately to book every night at 12:01 their fitness class. On the other end we have big companies like big banks even that upgrade their mainframe with N8N and literally anything in between.
There are for sure a few use cases we have focused on more about, one is for example around security. That's where we see a lot of interesting usage right now because the product fits very well there. People are more technical, they have some of those very specific use cases that are very accustomed to what they need to do for their company. So we have actually two major telecommunication companies that use N8N for accepted use cases because it's so flexible. They self-host it, they know exactly where the data's lying. They don't have to worry about any security host anything because it runs in their own data center. And that is really what those people value and that's why it's working so well for those use cases.

Eric Anderson:
And maybe to help people frame likely use cases. Generally these are ones where there's some trigger that begins a workflow and maybe these are steps that people often complete manually and it gets increasingly tedious and they decide we need to automate this side thing and.

Jan Oberhauser:
Exactly.

Eric Anderson:
Is that fair?

Jan Oberhauser:
That's fair, yeah. And you have the different kind of triggers, normally they're like few main ones. The most are either time based, to do something at a specific time or do something when there's something externally happening. For example, I don't know, every time you get a new lead in Pipedrive or got something from Typeform or somebody calls a specific URL. Or you get a new message in Rapid MQ or Kafka that can start a workflow and then again each note can do something in an application.
We have specific notes that again, do something that for example in Pipedrive, create a new lead, or a new deal. Or send a Kafka message or make literally anything in any tool, you can create notes for and be out of a second class. Which is this very generic notes for example, send a generic HTP requests to a service fee for example, don't have a native integration for. Or receive generic webhooks just to start a workflow or transform data and that's more or less how N8N works. You have trigger notes that start a workflow and generic notes, regular notes that transform the data or can make any kind of action that is possibly [inaudible 00:17:17].

Eric Anderson:
Got it. Jan, I'm curious when I think about go to market or how people adopt N8N, I imagine with Zapier that it's a lot of individuals, I could be wrong. But an individual has a pain point and rather than asking their team to solve it for them, they go and use personal OAuth and script something together. How does it work with N8N? Is this also rogue individuals trying to solve something or is this become a team wide decision? We all agree with this needs to be solved and we turn to N8N for it.

Jan Oberhauser:
Actually we are our PRG motions very strong, it normally starts out with an individual. Many of them started to use N8N privately and then they use it for some how home automation sometimes or for their fitness classes mentioned before. Then I see okay, there's actually need at my work as well and then they start to adopt it. Normally it starts very small and then it starts to grow from there and then one department adopts it, then the team starts to adopt it and then other teams see it as well and then it starts to spread across the company like that.

Eric Anderson:
Got it, wow. And in essence you maybe have greater expansion possibilities than Zapier, I'm not sure Zapier moves beyond the individual as successfully as you do. You mentioned that you can host on-prem and other things like that that are palatable to larger organizations.

Jan Oberhauser:
Exactly. Actually I think that's the nice thing about our product, there are so many different use cases and every company has so many different of them there's not really a limit there. I think that the current limitation would be, if I would've to name one was really because we focus on this more technical people. In the long term we want definitely want to focus also on this less technical people, but I think that's really the main limitation right there. It's like that's what separates us for example, for Zapier, they focus on this knowledge workers that are not technical. While we really expect that people have some kind of technical background. They should know what a JSON is for example, maybe write a little bit of JavaScript code. And then they have a great experience within it and everything below that as if you would recommend them to use a different tool because we want to be very honest.
We want to make sure that we get the right people and people have a good experience. And sometimes it's the right thing to say, hey said, you're probably the wrong user right now. In a few years we are probably ready and when we support you then it's great, but for now there's probably the wrong tool for you. Or once you're ready or we are ready, definitely happy to have you back.

Eric Anderson:
Super. Maybe take us under the hood just a tiny bit, for those who are interested in the technical details. I imagine some technical users might wonder if they wrote a manual script to solve this if they could have greater reliability, maybe it handles errors better or maybe it would be more efficient. How does N8N match up to a well thought out manual script?

Jan Oberhauser:
Yeah, thanks for bringing it up actually it's quite interesting. If you call it our biggest competitors actually not really a product out there, the most people come literally from writing scripts because they write some Python scripts and then they switch to N8N. And the reason why they do it is actually more or less around what you just mentioned. If you write a script and something goes wrong, debugging it is not really fun, it's like it's stopped somewhere in the middle. Some data is half written somewhere and then even if you see the bug then it's not as easy to restart it because that's literally in the middle of a script somewhere. Then you have to comment some stuff out and try around, that's really not a good experience until you actually already find a problem. That is very different at N8N because you literally can open a past execution, you can directly see where it failed, you can see the error message. You can say, ah, okay, I didn't consider that edge case.
So you actually change your workflow, say restart and it starts to run again from that point in time moving forward. It's like being able to see problems and debug them is very easy. Also, around reliability, is like when a script fails and normally it fails and maybe you don't even realize unless you have written specific code that tells you about it failing and it sends you an email or sends you some other kind of event within it. And you can very easily set up an error workflow meaning it's a specific N8N workflow that runs every time a workflow for you is failing. So you can say, hey, every time my workflow fails, send me a Slack message or send me an email or whatever you want. Every workflow is it's own workflow can be as simple, as complicated as you want to.
It's like you get all of that for free. Also what you save is the whole deployment part, it's like you don't have to upload it somewhere, find a server, all of those things and then again set up as certificates. And once it does that, you press new, create a new workflow, set it up, press save, activate and it's running. Disable it and it's deactivated. And another important point is around collaboration. What we see very often is what I mentioned before in my experience in the V-effect world. It's like do you have people that have a problem, they fix a problem themselves. Let's say then actually two possible ways, you have somebody less technical, they start a workflow and then they get stuck. Then they get help from a more technical person that figures out a complex part and they keep on finishing the workflow and they start maintaining it. And every time they have a bigger problem they would contact again and there's more technical person.
But for the most things they don't have to go back to that other person because they can maintain it themselves. Also the other way around, you have a more technical person starting a workflow but then they give it to somebody less technical to maintain it. It just allows less technical people to do tasks that only previously and more technical could do. And again it enables those people and empowers them to actually being free or be independent of this technical person, of their time because you always end up in this kind of little bit of this begging position, "Hey, when you have time, could you please." That's never nice, this person knows something I don't know and that person has the power and I'm independent on them, that's never nice. And it ends, one of our core values is empower others. It's like really we want to empower people to help themselves and there could be this less technical people that are totally unable to do something before but there could also be the technical people to do something faster and for more people and can so do more and less time.

Eric Anderson:
What's the future look like for N8N? I think you hinted at some things while we chatted here. You mentioned maybe you want to address less technical users somehow. Maybe help us understand where the project's at today and things you're excited about in the future.

Jan Oberhauser:
Sure, yeah. We're still a young small company, we cannot be everything for everybody simply doesn't work. The product theoretically is able to do that but the organization isn't ready for that, we simply don't have the scale. That's why we focus on this more technical people for a few specific use case for example security. In the long term, one of our mission is to give everybody who uses a computer technical superpower. So we really want that everybody can use N8N and enable them to do whatever they want to do so. So it means it should just not go down the ladder in sense of how technical they are, but as well we also expanded the kind of use cases. And in the end the idea is more around making the same possible. Initially we have a single product that enables others and then empowers them and as we grow there definitely many other ways that we're thinking about how we can make the same possible in other ways with other products and so on.

Eric Anderson:
Jan, I noticed on your website, we mentioned this before the show that it's listed as source available. And you have some history in selecting the license and the approach to open source. Maybe you can tell us about how you did that and as I understand it, you had some issues along the way.

Jan Oberhauser:
Yeah, that's true. While I was creating N8N I was thinking about a lot about the license to use. There are obviously a lot of open source licenses out there, but at the same time did also see that more and more open source projects started to change their license. Because at some point they realized it wasn't sustainable, they wanted to build a company and the license caused problems for them. And then I also saw especially in Hacker News that for example somebody like Elasticsearch changed the license because somebody like Amazon used them without paying. But people said, "Hey, yeah, that's their own fault. You chose an open source license, an open source license allows exactly to do that. Don't complain, they play by the rules. You made the rules, you're not the one to complain about it." And I definitely didn't want that.
And it's never good to take something away people had before, nobody wins there, that's just bad. I think being upfront about something is always, always best. And for that reason when I launched I made sure that I thought it through and that's why I chose back then the Apache two license with the commons clause. And it was not OSI approved open source anymore. The problem was that there is no good term out there to describe what we were, there's open source and there's source available. There's also OSI approved open source because open source is actually not really a protected term. But that the OSI obviously wants to have it that way and that's why you always have to be careful there. So I didn't want to use source available because the problem with source available is that it doesn't have a definition.
If you look on Wikipedia, it literally describes it as the source code being available. Meaning you have approach that is MIT license, that source available. If the a project doesn't have a license or has a license that allows you to do nothing, just look at a codes also source available, it actually doesn't have a meaning at all. So I thought, okay, well how can I describe it in a way that people actually get the best idea what is possible in it? And so I described it as open source, I put it in quotes and I described everywhere, Hey, it's not OSI approved open source. You can do it all the stuff you can do with open source, but what he cannot do is to commercialize our code. So you cannot, for example, offer a hosted version of N8N. For the simple reason because when I thought about N8N, the plan was always to make money with the project, I want to live of it just like I wanted to have a job, I wanted to spend my whole time on the project.
The problem with the most open source projects is that because of that [inaudible 00:28:41] for example saw with Elasticsearch and AWS that a lot of value that gets created doesn't actually end up with the company behind the project and doesn't go back into the project for that reason. It literally goes to the other company, makes poof and it's gone. It could provide so much value for the product and especially for the community, but it simply goes away. So I thought, okay, how do I make sure it doesn't happen? And then again, that's why I chose Apache two with commons clause because it protected N8N. The problem was when we launched it, people didn't really like it. Some people didn't care, but obviously some people care very much about it. Like about many things, there's a few people that obviously if you're very involved in the OSI you're not going to like it if somebody is in their eyes is really totally using the term in a wrong way.
And so people started to complain about it. There's like this very long threat and a GitHub issue. So if anybody's bored, they type in Gaslight. N8N you find it very easily via Google and you can literally read for probably two days through the whole discussion there. But in the end how it ended is that I agreed and said Hey, okay, we stopped using the term open source, we'd rather create something else. What we then called fair code license, meaning fair code means in the end is see pretty much what I described before. You can do everything with the code more or less that you want but you cannot commercialize the codes to make sure that the most financial gains actually goes back into the project, which helps everybody. And then we removed every open source reference and at the same time did we also create a new license. Okay, not at the same time a little bit later actually, which is called sustainable use license, which is based on the amazing elastic community license 2.0.
And that exactly follows now to start exactly what we want to allow, what we don't want to allow. And I think in hindsight it was a very good decision to be always very upfront about what we expect. And I didn't want that the people feel cheated and say, "Hey, I contributed because it was open source, I contributed because of that. Because I thought hey, he's just doing it out of the good of his heart." I try to be a nice person but I still want to eat and I have a family and we have a lot of people to pay and I care about the project and I really want to make sure it's sustainable long term. I think it's the best and I think with the license and how we are doing it, I think we give the company, the project the biggest chance of being big and successful and everybody along to use it long term.

Eric Anderson:
Your experience here is really helpful and unique I think to a lot of other founders who probably wrestle with the same thing. You've got an impressive community and adoption. I imagine people in your shoes might feel like, oh, if I do this fair code option it might limit adoption. Do you feel like the approach you're taking with licensing has limited adoption? Because it's not clear it has to me.

Jan Oberhauser:
I think that definitely, it did for sure a little bit. It's like you have some disadvantages. Again, not being able to use open source, it's always harder for people because like nobody has the idea to Google open source ties alternative for open source. For a cart alternative, they Google that but we would normally not show up because we cannot use open source there. Or there's some lists because the most time when open source get mentioned that it say as defined by OSI. So you normally out there, for example, I remember there was this digital ocean, heck, how's it called? Heck, something. Yeah, they have a second one where they give away t-shirts and actually I wanted to participate there. So I wrote them said, "Hey, can we participate because we're not OSI approved open source?"
And they answered and said, "Yes, it's fine. As long as the source code is on GitHub and it's open, you can use it, you can attend." So actually we did, I think we didn't get a single contribution back then but again we were there. But the interesting thing was that actually when somebody wrote them an email and complained said, "Hey, there's not OSI open source, they should not be able to attend." And they kind of pulled back then, that happens quite a lot. That people say, "Hey, it's fine to participate if you open source, but then people complaining." And then actually people don't want to anger people because this OSI community they're quite loud. Yeah, it brings them more risk than actually gain. So there's definitely I think the short term there are some smaller losses but I think it becomes also quite much more normal.
I literally just checked today and looked at a few projects that partly a little bit competing to us and many of them actually not OSI approved open source, they actually use custom licenses. Interestingly they still use the term open source, I guess they're still smaller that nobody cares there. But it's quite interesting, it's actually goes more and more in the direction of having custom licenses there. They also talk with founders of larger open source projects that actually switched away or party also didn't. They ask them, "Hey, should we be OSI approved open source?" And the answer they got more or less from all of them is that it doesn't matter, nobody cares anymore. It's quite interesting, so it doesn't matter. I'm sure it gives some disadvantages, but in the long term if it's the right thing for the company, it's an important decision, I don't think everything should be not open source and there's a very good reason to be open source.
Especially if you have lower level libraries, if you're not open source it doesn't make sense. But it's really has to be an active decision, it shouldn't be the default. Like with everything, you have to think through of your options, advantages, disadvantages, not just like ah, obviously it has to be open source and actually at some point realize it probably shouldn't. And then you're screwed because then you literally have to either stay that way or make everybody very, very unhappy because if you kind of cheated. They have a reason to be because obviously you change the rules afterwards.

Eric Anderson:
Yeah, right. I wonder if the OSI would ever consider some kind of qualifier. There's wheat bread and then there's whole wheat bread and maybe we need fully open source and then we could all use the open source term the way we want to.

Jan Oberhauser:
It's actually very funny, there was this whole discussion I mentioned on GitHub with gaslighting people. And actually the president back then of the OSI reached out to me and we had a long discussion with him about it. Proposed exactly the same thing, this kind of a level system. You have like it on a level one, which is the current definition. You have level two, which takes away the commercialization rights, level three, something else. Actually, I really liked the guy, he's great. He was super friendly, we had a good discussion. But yeah, it's definitely nothing they were interested in. Maybe in time as it moves more in that direction, maybe they have to. But back then, which was again 2019, it was very far away but I think at some point I guess the pressure is going to increase and maybe it's going to change.

Eric Anderson:
Super. And your project is important for that process. Because I think you're right that people aren't going to make a decision ahead of you proving that the world wants source available software. Because I think what many don't realize is that open source, companies that adhere to OSI licenses end up doing other things over their lifecycle to make themselves more commercially viable. That I think maybe hurt communities more than the source available Licensing.

Jan Oberhauser:
Yes, actually. Actually saw quite a few products, for example, one competitor that he writes, they created themselves because there was no open source version. Because you're not open source, they created another one. The funny thing is they chose the, what's the right words? The most limiting open source license out there. Because that's quite interesting that it's literally even those people are aware that there are disadvantages. There's definitely going that direction, there are a lot of projects out there that they are open source, but literally if you have a problem, they're not going to answer your question. You're on the forum, nothing. Unless you're paid user, you will not hear back at all. I get this error message that says, error 227, what does it mean? Nothing, no documentation, I think that's the difference.
But I definitely help in our case for the community, no matter if you're paying user or free user, everybody can come to our forum and we help them out. They have an amazing experience because we have three great people doing that full time, taking care of our community there. We offer also paid support for enterprise users, that's paid. Again, they can write us personal messages, we don't do any email support for free. Again, it's not very scalable and if you answer question that it also helps other people. But again, everybody gets an amazing experience no matter if they're paid or not. And I think some open source projects are missing, people really look what can I do with the code? They don't look at the whole product and the whole community and what the product is generally doing.
And trust me, also a lot of companies at some point they remove the open source reference totally from the website. It's like as soon as they want to commercialize like that, they start to hide the fact that they're actually open source. Yeah, that's obviously disadvantage and advantage with each of them, but it's quite interesting how it's heading. I think there's not so clear, a good and bad how people always want to make it seem you open source, you're good and you're not open source your bad. I think there are other things people should considering as well and I think at least be true to try to do the right thing there. And I think it's paying off and I think people see that as well, even though we are not OSI approved over source, yeah.

Eric Anderson:
Super. Jan, thanks so much today. There's more we could talk about, unfortunately we're bumping up against our allotted recording time. Anything you wanted to add before we wrap up?

Jan Oberhauser:
No, thanks. I really had a great time. Really it was helpful for some people, especially the people that start to think about creating a project or they're about to release it. Really think about the license, what kind of product you want to build, especially what kind of community you want to build and what really matters. And I think that doing stuff intentionally, it's really important and being upfront about things is always the right thing. That really going to pay off in the long term, it's going to be painful in the short term maybe, but in the long term it's really going to be worth it. And obviously thank you for having me. Had a good time.

Eric Anderson:
Awesome, Jan, thank you so much and we'll have to revisit how things have gone years from now.

Jan Oberhauser:
Sounds great. Thanks. Bye.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and Newsletter at contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson and this has been Contributor.