Live data from Hacker News

Show HN: Drop-in SQS replacement based on SQLite

github.com

101–110 of 171 posts

Re: Show HN: Drop-in SQS replacement based on SQLite

#101
post #96

Earlier quoted context omitted.

What is your target market? Cloud-native is, like the commenter said, going to be difficult to differentiate based on cost. I can see this being useful for hybrid cloud (onprem instances), functional or local testing, “localfirst” workloads, enthusiasts etc.

Now you sound like an investor :) My own vision is to take a queue that is relatively dumb and make it smarter. I want it to be able to, for example, allow you to rate limit workers without needing to implement this client side. And so on for all of the other bits that one needs to implement in the course of distributed processing. I’m still figuring out the market. Very large firms spending thousands of queues? Or d…

I've heard this use case come up in hybrid new/legacy products where there is a chasm between legacy scalability (probably a monolith in the compute or storage layer, or both). The "new" side needs to be able to self-regulate and if you can put that into the service-side it would it would be a helpful transition enabler (and, let's face it, given these transitions often never finish your product would be effectively sticky).

I don't think the cost of queues is a problem anywhere (I'm sure it is somewhere, but not a market's worth). The problems created by queues, on the other hand, are myriad and expensive.

Re: Show HN: Drop-in SQS replacement based on SQLite

#102
Correct me if I’m wrong but: SQLite sounds like: runs on one server. While that will work most of the time, it won’t work 100% of the time. I don’t know the specifics, but I’m fairly sure if a queue server crashes, SQS will keep working, as stuff is redundant. So while it can work in a best case, this (probably) won’t have the same reliability as SQS has..

Re: Show HN: Drop-in SQS replacement based on SQLite

#103
post #102

Correct me if I’m wrong but: SQLite sounds like: runs on one server. While that will work most of the time, it won’t work 100% of the time. I don’t know the specifics, but I’m fairly sure if a queue server crashes, SQS will keep working, as stuff is redundant. So while it can work in a best case, this (probably) won’t have the same reliability as SQS has..

I break it down two ways.

First, the project does not yet have a distributed implementation, you’re correct. Stay tuned!

Second, SQLite is incidental. Data is still stored on disk, just as SQS must be, but I’ve chosen SQLite as the file format for now.

Re: Show HN: Drop-in SQS replacement based on SQLite

#104

Earlier quoted context omitted.

It's right there in the LICENSE file: https://github.com/poundifdef/SmoothMQ/blob/main/LICENSE What's unclear or not transparent about that?

All I'm asking is to include the type of license in the Show HN title I had no idea there would be so much push back against this.

I actually agree.

The AGPL, for something like this, is a total non-starter, IMO, and just changes the conversation.

It'd be one thing to choose the AGPL because you believe in the FOSS movement. Or if you're releasing something end-users can benefit from, directly, by self hosting it.

To release something that will always be a component of something bigger, license it as AGPL, then talk about monetization… just cut the chase and release it as “source available,” with a licence people can actually use, even if it has a bunch of not-really-FOSS strings attached.

Because who can realistically use this as is? Who can download the source and actually do something with it? What AGPL-compatible FOSS project is dying to use a drop-in AWS SQS replacement?

Re: Show HN: Drop-in SQS replacement based on SQLite

#106

Earlier quoted context omitted.

All I'm asking is to include the type of license in the Show HN title I had no idea there would be so much push back against this.

I actually agree. The AGPL, for something like this, is a total non-starter, IMO, and just changes the conversation. It'd be one thing to choose the AGPL because you believe in the FOSS movement. Or if you're releasing something end-users can benefit from, directly, by self hosting it. To release something that will always be a component of something bigger, license it as AGPL, then talk about monetization… just cut…

Just from IP/legal point of view AGPL and AGPL adjacent licensing that imposes control over how you use the code is a non-starter for many companies especially ones that are "backed by YC" proudly displayed on their website because that signals money will be exchanged in the future by design.

MIT/BSD license that imposes no control over the how the code is used is the only FOSS we are allowed to use and we do donate regularly to maintainers working selflessly.

What makes me angry is that somebody then uses that MIT/BSD license code, makes some modifications and releases it as AGPL with clear intent to make a buck from it without paying that original maintainer any money.

Re: Show HN: Drop-in SQS replacement based on SQLite

#107
post #41

Earlier quoted context omitted.

What's the point of AGPL though? The enterprises with the budget for self hosting this sort of software usually have requirements and scale beyond what SQLite can offer out of the box.

Ugh I didn't see that. My enthusiasm has instantly waned. Why is AGPL needed? Just be MIT and make it easy for people, espefcially if you're not planning on monetising it. I won't use AGPL code just on principle.

Why? Does AGPL really matter if you're not planning on monetising whatever it is you're using it for?

Not trying to be snarky, I'm genuinely curious why you'd be so vehemently opposed to it.

Re: Show HN: Drop-in SQS replacement based on SQLite

#108

Earlier quoted context omitted.

I actually agree. The AGPL, for something like this, is a total non-starter, IMO, and just changes the conversation. It'd be one thing to choose the AGPL because you believe in the FOSS movement. Or if you're releasing something end-users can benefit from, directly, by self hosting it. To release something that will always be a component of something bigger, license it as AGPL, then talk about monetization… just cut…

Just from IP/legal point of view AGPL and AGPL adjacent licensing that imposes control over how you use the code is a non-starter for many companies especially ones that are "backed by YC" proudly displayed on their website because that signals money will be exchanged in the future by design. MIT/BSD license that imposes no control over the how the code is used is the only FOSS we are allowed to use and we do donate…

I actually have no beef with either “money will change hands in the future” or “AGPL because we want to advance FOSS.”

The problem is that AGPL is a total no starter at “day job,” and even at “side gig,” I'm obviously not going to release the source code of the entire service because of a message queue dependency.

I mean, if I was trying to switch clouds for whatever reason, I might want this, and could even be persuaded to pay to self host it.

But at this point there's no pay option. Just source I couldn't possibly use, not even for a month, not even as a trial, company policy or no company policy.

It makes no sense.

Re: Show HN: Drop-in SQS replacement based on SQLite

#110
post #72

Earlier quoted context omitted.

The purpose of Show HN is not really ‘product catalogue’

i didnt ask for a product catalogue, all im asking is to clarify whether you are truly FOSS or not by being transparent about the license. Any type of licensing conditions like AGPL 3.0 to force you to share your code is a no go for many many companies. I understand the desire to make money and you can do that without AGPL 3.0

AGPL 3.0 is _absolutely_ “truly FOSS”. Probably the most “truly Free Open Source Software” license in existence.
Post reply on HN