- Your pricing conflicts with your open source users. You need them to build and improve the product but you also want them to have a worse experience otherwise your cloud-hosted solution will not prevail.
First off, thanks for this feedback – it makes it clear that we need to do a better job.
We're following the GitLab open core model. Our licensing is the same as their's (and many other open core companies).
This means that all existing code and the vast majority of future code will be under the MIT license. At some point, we will add some enterprise features that are in /ee folders and they will be licensed differently. This is to protect us against a competitor taking the code and launching an alternative hosted service without any effort on their part. We felt that this was a friendlier option than going with something like AGPL.
Sorry that our self-hosting guide isn't available yet, we will get it up really soon. We want people to use Trigger.dev and that includes self-hosting.
There are lots of open core companies that have a cloud version and the ability to self-host. I don't think that our business model conflicts with being open source – anyone contributing will make the experience better for everyone (cloud or self-hosted).
Hopefully this answers your questions and helps to alleviate your worries about the project. We are big believers in open source and have thought hard about how we can create something valuable for everyone.
I’m having trouble seeing the issue here. It’s not uncommon for open source projects to offer hosted services for a price. Seems like a reasonable way to generate revenue to me.
I’ve dabbled in self hosting, and I enjoy it, but sometimes it’s not worth my time and energy. If there is a product I really like and gives me value, I think having the option to pay them to host is a win/ win. I’d rather have that option then not.
As far as the missing self hosting guide, there is a section for it at the bottom of the README that says “Coming soon”. They stated they have only been working on this for a matter of months, and this is an early beta version. I’d imagine the team has been fervidly working on the core product & features, therefore finishing this part of the documentation keeps getting punted down the line.
It’s clearly going to be an option, so I feel like your judgment is a little harsh. I’m willing to be patient, and test drive the product on the free tier in the mean time :)
I always check the license first and this is not too nice. These mixed licenses are a real nightmare for companies and their lawyers. Keep it clean & simple or there won't be a lot of adoption really.
We're using the open core model that Gitlab use. It's popular because it mean 95% of the code is MIT (good for everyone) and a small number of enterprise features are under a different license. This puts off bad actors from building a commercial competitor with zero effort. The alternative we considered was AGPL but that felt worse for our open source users.
I don’t see an ee folder or ee/LICENSE so according to their license, everything in their repo seems open source although annoying they did this instead of just a real OSI recognized license.
Not having install docs isn’t the end of the world if I can figure it out and contribute back. But I don’t want to waste my time if it’s not actually open source and my work will be commercialized by a single org.
I don’t mind contributing for everyone to do whatever (including commercialization) but am not into doing free labor for a profit enterprise.
All the code that has been pushed so far is under MIT and we currently have no enterprise features (/ee folders). The majority of future code will fall into this same bracket.
Some features that are for "enterprise" will be put in /ee folders – ideally we will put all of that in a single /ee folder in the root but we wanted to cover the case where that's non-trivial to implement.
This open core model (that Gitlab use) is popular because it strikes a nice balance between having an open source project (good for everyone) and it puts off bad actors from building a commercial competitor with zero effort.
The wording suggests to me that there can be ee/ subdirectories scattered all through the directory tree, and within those the different licenses apply.
Right? They advertise as an "Open-Source", MIT and self-host. But then they make it difficult (you need to figure out how to install this thing, lol). That would be understandable if this was done pro-bono (the paid service didn't exist). But they have a team and a paid service behind me.
It's not the model that bothers me (if you want to mix OS with SaaS/Paid, then it's all good) but the false and dark-pattern advertising.
- Advertised as "Open Source", yet this is actually a paid product with a pricing page.
- You don't even have a guide on how to install this thing... euh, I mean what's the point of this if I can't use it?
- You have a complicated license: https://github.com/triggerdotdev/trigger.dev/blob/main/LICEN.... You might have an "open" source as anyone can see the source but it's not as open as say an MIT license for the whole project.
- Your pricing conflicts with your open source users. You need them to build and improve the product but you also want them to have a worse experience otherwise your cloud-hosted solution will not prevail.