Hacker News Reader

Comment by PeterZaitsev | Hacker News Reader

Looking at the License - This is not Open Source, but rather Source Available software.

Looks great but do not appreciate deceptive marketing

And it seems their misnomer is practically everywhere, not just in the Show HN: their website also mislabels their links as "Open Source" - I guess trying to capitalize on SEO

SSPLv1 for anyone similarly interested https://github.com/inngest/inngest/blob/v1.0.0/LICENSE.md

Seems they had a change of heart around 2022: https://github.com/inngest/inngest/pull/81 but they actually only started lying about the license in this go-around because their previous Show HN <https://news.ycombinator.com/item?id=36403014> not only didn't mislabel things but they even said "we're gonna open source in the future" but I guess the future isn't here yet

We'll roll out a change that releases source as GPL after 3-4 years next week, actually. I do appreciate these comments and points.

Why is it necessary to wait? You've already seen the feedback, if you're going to change the license, why promise to do it later?

It's already planned, and rushing out a legal change on a Friday night ahead of plans is less than ideal.

Is there any guarantee ("don't take promise from a company") the license won't be changed to something more closed some time afterwards?

So "eventually OSS"? That's certainly better, especially so for some use cases (company goes under), but it isn't OSS either.

Why not dual license with AGPL?

don't let that stop you from using it marketing though.. if you're misleading with your marketing it makes me wonder what else is not as it is claimed.

BSL Is also not Open Source, it is another kind of Source Available issue.

Of course you're free chose the license what is right of your business, but trying to use Open Source name in deceptive marketing is the problem.

And the production infra for running isn't even available, just a pared down "development server" via SSPL. This is a long way from OSS.

Well, my experience has been closer to the "more eyes make for shallow bugs" school of thought, so opening the source to contributions would actually help that process, not hinder it

I've written quite a lot of CI for projects because it's something I believe in and am willing to roll up my sleeves to get done (as a concrete example). I believe strongly that being able to reference the canonical CI build helps contributors since they can see how it's built for different systems and also ensure they don't submit "works on my machine" patches

There might be a bit of misunderstanding on what's in that git repo here. It actually contains the executor, state store, queue, and our production UI, plus the syncing, registration, and logic for functions.

Earlier this year we didn't want folks to roll their own production cloud due to queueing migrations. It would make your life hard. We're entirely responsible for that right now, as we discouraged self hosting.

That's actually coming to a close, and we'll make it easy to spin up prod clusters using this code and eg. MemoryDB, Dragonfly, or what have you.

Let me know when you do! I like the pattern and APIs you've designed for the SDKs—and would probably rely on a managed coordination layer like you've got. But, in order to build confidence in any product like this, we have to know that if something happened to the co, or you went another direction, we could fork the core and continue on.

Agree. This is absolutely deceptive. It's too bad how the OSS moniker is being misused these days...

I opened the comments before the website as I was sure this would be another of those sources available clickbait. Why is this kind of disingenuous move not enforced in the title guidelines of HN is beyond me.

Reply on news.ycombinator.com