They still have linked their OpenCollective account, where they have raised $10K and still have a balance of $5K. [0]
It's not a lot in the great scheme of things, but, have they been using a platform that's seemingly built for communities and open source to bootstrap their business?
Because this is not a 'open core' situation. They just closed the repo and ran away. If they had that idea all along, I feel like it hasn't be very, let's say, ethical.
Wait, so a company shared their work with the public for however long, then decided to leave what was shared up ... but stop sharing ... and you're upset?!?
They did everything properly by the rules of OSS, decided it wasn't in their best interest to keep doing OSS, and left all their code available, as required by OSS. They were a textbook good participant.
Meanwhile, 99% of companies never open source anything: why aren't you complaining about how "unethical" they are?
> and left all their code available, as required by OSS.
IANAL, and I don't have a horse in this race, but I don't think that's required by OSS, not by the spirit of "the law", and (at least) not by GPL, MIT, and other similar mainstream licenses.
The spirit of open source is: you buy (or just download for free) a binary, you get the 4 rights. Whatever happens when the developer/company stops distributing (whether at a cost or free as in beer) that binary is completely outside the scope of the license.
You only have the right to modify if you can access the source.
If you got (a snapshot of) the source along with the binary, that's fine, there's no need to keep hosting the source anywhere.
But if the company said "for source, see: our github", then that github has to stay up/public, for all the people who downloaded the binary a long time ago and are only getting around to exercising their right to modify today.
They don't need to post new versions of their software to it, of course. But they need to continue to make the source available somehow to people who were granted a right that can only be exercised if the source is made available to them.
(IIRC, some very early versions of this required you to send a physical letter to the company to get a copy of the source back on CD. That would be fine too. But they'd also have to advertise this somewhere, e.g. by stubbing the github repo and replacing it with a note that you can do that.)
> a company shared their work with the public for however long, then decided to leave what was shared up
More like a company took advantage of a community that expected their freely offered labor to not be commercialized at any point in time without making available said works in a fully free vector as well, as that's an implicit expectation behind "open source".
It would be helpful for everyone if that community would pause before contributing to code bases with licenses which allow for that. MIT, BSD, Apache, …
It would be helpful for them because they’ll know what they’re getting into. For us because we won’t have to see this tragedy unfold time and time again. And for all open source users because more efforts will be directed towards programs with licenses that protect end users. GPL, AGPL, …
It will be a little worse for companies seeking free labor. A price I’m willing to pay.
It looks like it's Apache licensed, so this was the expected and intended outcome for contributors. If they wanted their work to remain free and not become proprietary, they should have only contributed under perma-free licenses like GPL.
Companies stand to turn a profit. OSS is here to help enable that or push the goal posts. It’s not a charity unless the org feels charitable. Sure, non-profits exist but they were never one of those.
I think the comment on corpos is good, but calling the naive people fools might be unnecessary - it’s probably not their fault nobody told them about this sort of thing before and learning that lesson is probably disappointing enough already.
It’s unfortunate that this keeps happening to projects like MinIO and others too.
Sure! Slightly edited the tone, but I’m noticing that often people have idealistic attitudes about FOSS until they get burnt by bad faith actors or even just indifferent corps that have to keep the lights on. Quite unfortunate, definitely not their fault. Pity is correct.
It’s definitely pity. It’s a hard pill to swallow when you were led to believe a certain world view of an entity only to find out they were milking your data.
I can't think of any free or open license that requires you to leave your code available for any specific period of time if you are not simultaneously distributing binaries.
How can people still not understand that OSS can be abused?
It doesn't matter that the previous code is still available. Nobody can technically delete it from the internet, so that's hardly something they did "right".
The original maintainers are gone, and users will have to rely on someone else to pick up the work, or maintain it themselves. All of this creates friction, and fragments the community.
And are you not familiar with the concept of OSS rugpulls? It's when a company uses OSS as a marketing tool, and when they deem it's not profitable enough, they start cutting corners, prioritizing their commercial product, or, as in this case, shut down the OSS project altogether. None of this is being a "textbook good participant".
> Meanwhile, 99% of companies never open source anything: why aren't you complaining about how "unethical" they are?
Frankly, there are many companies with proprietary products that behave more ethically and have more respect for their users than this. The fact that a project is released as OSS doesn't make it inherently better. Seeing OSS as a "free gift" is a terrible way of looking at it.
> It doesn't matter that the previous code is still available…The original maintainers are gone, and users will have to rely on someone else to pick up the work, or maintain it themselves.
It does matter: popular products have been forked or the open-source component was reused. E.g. Terraform and OpenTofu, Redis and Redict, Docker and Colima (partly MinIO and RustFS; the latter is a full rewrite, but since the former was FOSS and it’s a “drop-in binary replacement”, I’m sure they looked at the code for reference…)
If your environment doesn’t have API changes and vulnerabilities, forking requires practically zero effort. If it does, the alternative to maintaining yourself or convincing someone to maintain it for you (e.g. with donations), is having the original maintainers keep working for free.
Although this specific product may be mostly closed source (they’ve had commercial addons before the announcement). If so, the problem here is thinking it was open in the first place.
To be clear, colima isn't a fork of docker. It's just the lima VM with the docker OCI runtime + cli which is FOSS and always has been. Docker Desktop is the pile of garbage you can kinda sorta replace it with, but PodMan and PodMan Desktop is closer to a clone of Docker than Colima. Colima _is_ Docker
You might want to get your arguments in order. In one sentence you're calling OSS rugpulls a problem, and then in another you're claiming that proprietary products behave more ethically.
So which is it? Is it less-ethical to have provided software as open source, and then later become a proprietary product? Why? I see having source code, even for an old/unmaintained product be strictly superior to having never provided the source code no matter how much "respect" the company has for their users today.
You might want to think about my argument a bit more.
> Is it less-ethical to have provided software as open source, and then later become a proprietary product? Why?
Because usually these companies use OSS as a marketing gimmick, not because they believe in it, or want to contribute to a public good. So, yes, this dishonesty is user hostile, and some companies with proprietary products do have more respect for their users. The freedoms provided by free software are a value add on top of essential values that any developer/company should have for the users of their software. OSS projects are not inherently better simply because the code is free to use, share, and modify.
To be fair, I don't think a developer/company should be expected to maintain an OSS project indefinitely. Priorities change, life happens. But being a good OSS steward means making this transition gradually, trying to find a new maintainer, etc., to avoid impacting your existing user base. Archiving the project and demanding payment is the epitome of hostile behavior.
It seems like you’re trying to build a system of ethics around being annoyed by OSS maintainers not working for free in perpetuity.
Having access to Apache licensed code that you can build off of is better than never having access to any code at all. Anything else about values or respect has to be inferred or imagined and has no bearing on the software itself.
Edit: Like who cares if they “wanted” to contribute to the public good? Did they actually contribute to the public good? It seems like they did and the code that did so is right there. If “life happens” then why are they obligated to do a smooth transition?
I love free stuff as much as the next person, hell, free stuff is my favorite kind of stuff. Is it annoying when there’s less free stuff? Yes. Does my personal irritation constitute a violation of a lofty set of ideals that just coincidentally dictates that nobody annoy me? No.
I would love to live in a world where it just so happens that it’s ethically wrong to bother me though. That would be sweet.
That's what they always do it always comes down to a sense of perpetual entitlement over the work of others, work they themselves would never do.
I've had the same discussion for years now on HN. It is not unethical to decide to stop supporting something especially if you played by all the rules the entire time.
No one is owed perpetual labor and they completely disregard localstack has been oss for something like 10 years at this point just celebrate it had a good run, fork and maintain yourself if you need it that badly.
It is incredibly weird to think something that was maintained oss for 10 years is a rugpull that's just called life, circumstances change.
> I've had the same discussion for years now on HN. It is not unethical to decide to stop supporting something especially if you played by all the rules the entire time.
What's unethical is taking yhe fruits of other people's work private: ranging from code contributions, through bug reports and evangelism.
Companies are never honest about how they intend to use CLAs and pretend its for the furtherance of open source ethos. Thankfully, there's an innate right to fork entire projects after rug pulls, whixh makes them calculated gambles amd nor a quick heist.
> What's unethical is taking yhe fruits of other people's work private: ranging from code contributions, through bug reports and evangelism.
First, if it's open source, then the contributions are still there for everyone to use.
Second, if the license allows it, then the license allows it.
Now, if the contributions were made with a contribution license to prevent it, you've got a solid argument. Otherwise you're applying your own morals in a situation where they're irrelevant.
I agree, along with the child comment. I think the issue is that if there wasn't some kind of ability to "rug pull," that we would see far fewer open source contributions in the first place.
I hate that a company can take a fully open-source project, and then turn it into a commercial offering, dropping support for the project's open source model. I am fine with a project's maintainers stopping support for a project because they have other things to deal with, or just are burnt out. I understand that both of these things are allowed under the specific license you choose, and still believe you should have the freedom to do what was done here (although not agreeing with the idea of what was done, I still think it should be allowed). If you want to guarantee your code is allowed to live on as fully open, you pick that license. If you don't, but want to contribute as a means to selling your talent, I still think the world would have far less software if this was discouraged. The source is still legal from before the license was changed, and I feel that even if the project doesn't get forked, it is still there for others to learn from.
With that said I'm wondering if there has ever been a legal case where source was previously fully open source, then became closed source, and someone was taken to court over using portions of the code that was previously open. It seems like it would be cut and dry about the case being thrown out, but what if the code was referenced, and then rewritten? What if there was code in the open source version that obviously needed to be rewritten, but the authors closed the source, and then someone did the obvious rewrite? This is more of a thought experiment than anything, but I wonder if there's any precedent for this, or if you'd just have to put up the money for attorneys to prove that it was an obvious change?
> Second, if the license allows it, then the license allows it.
I'm not arguing the legality. One can be a jerk while complying with the letter of the license.
I stopped signing CLAs, and I feel bad for those suckered into signing CLAs - based on a deliberate lie that they are joining a "community" - when the rug pull is inevitably attempted. I hate that "open source as a growth hack" have metastisized onto rug pull long cons.
> Otherwise you're applying your own morals in a situation where they're irrelevant.
Sharing my opinion on an HN thread about an open source rug-pull is extremely relevant.
The ethical problem is the bait-and-switch. A project that begins open and remains open is no problem; a project that begins closed and remains closed is no problem (ethically); a project that begins closed and becomes open is no ethical problem either. But a project that begins open, advertises their openness to the world, uses their openness to attract lots of community interest and then suddenly becomes closed is pulling a bait-and-switch, or rugpull.
> a project that begins open, advertises their openness to the world, uses their openness to attract lots of community interest and then suddenly becomes closed
Do you have any examples of that happening? When I click on the link at the top of this thread it takes me to a GitHub repo with a bunch of Apache licensed code that is open to anyone that wants to use or modify or build off of however they want. Heck, with permissive licensing like that you or I could fork it and put any part/all of that code into a proprietary product and make money off of it if we wanted to, and that would be entirely in keeping with the spirit and practice of FOSS.
This project seems perfectly open from what I can see, looks like the original devs stopped working on it though
It's remarkable that people think releasing a project as OSS is a license to disrespect users. This isn't even related to OSS. Software authors should have basic decency and respect for the users of their software. This relationship starts with that.
Publishing a project as OSS doesn't relinquish you from this responsibility. It doesn't give you the right to be an asshole.
And yet we fall for this trap time and time again, and there are always those who somehow defend this behavior.
I think it's an inherent conflict with the entrepreneurship mindset and those who visit this forum. Their primary goal is to profit from software. OSS is seen as a "gift" and an act of philanthropy, rather than a social movement to collaborate on building public goods. That's silly communism, after all. I'm demanding that people work for free for my benefit! Unbelievable.
"Software authors should have basic decency and respect for the users of their software." Why? Not at all.
"Publishing a project as OSS doesn't relinquish you from this responsibility. It doesn't give you the right to be an asshole." You are free to be asshole and it's nobody's business.
Actually it's exactly opposite. Such feeling of superiority and privilege, that just because you use some software, you have any right to command its author is the very definition of being an asshole.
"I'm demanding that people work for free for my benefit! Unbelievable." Yes, that's unbelievable.
> "Software authors should have basic decency and respect for the users of their software." Why? Not at all.
Because that's the core reason why we build software in the first place. We solve problems for people. Software doesn't exist in a void. There's an inherent relationship created between software authors and its users. This exists for any good software, at least. If you think software accomplishes its purpose by just being published, regardless of its license, you've failed at the most fundamental principle of software development.
> you have any right to command its author is the very definition of being an asshole.
Hah. I'm not "commanding" anyone anything. I'm simply calling out asshole behavior. The fact is that software from authors who behave like this rarely amounts to anything. It either dies in obscurity, or is picked up by someone who does care about their users.
> "I'm demanding that people work for free for my benefit! Unbelievable." Yes, that's unbelievable.
Clearly sarcasm goes over your head, since I'm mimicking what you and others think I'm saying. But feel free to continue to think I'm coming from a place of moral superiority and privilege.
If you want software to be free for everyone except for the authors to use, modify, distribute, and sell without restriction I am sure you could work with a lawyer to draft a new “Apache for everybody on earth other than the maintainers, who permanently waive all rights” license.
If that’s what all good maintainers do, and intend to do, there’s really no reason for maintainers to tempt themselves by using awful “open” licenses that allow them the loophole of doing what they want with the software they create. Plus who wouldn’t want to codify that they’re not an asshole?
It shouldn’t be hard to get maintainers that intend for their software to “amount to something” to adopt it, and it would bring a sense of comfort to the people that rely on the software that you write when you announce that it’s the new default license for everything in your repos.
Your argument is about some sort of covenant between the developers/maintainers and the users. That’s what a license is. That is the agreement between the parties. In that sense your problem isn’t with individual developers, it’s with permissive licensing.
If you don’t like it when OSS maintainers pivot to proprietary software, why not just create a license that precludes that from happening? The maintainers could waive their rights to pivot or later reuse the code that they wrote in any proprietary software, and that way people could just choose to only create and use NoRugPullForeverEver-licensed software and avoid the headaches altogether.
It's a matter of honesty and trust. A company that has never provided source code is more honest and trustworthy than one that provides source code, extracts community labor (by accepting issues and/or PRs) and then makes off with said labor (even if they left a frozen version available) at a future point.
Does the amount of labor that was provided by a community make a difference? What if it was minimal? Where do you draw the line (any piece of code accepted, or a "large portion" of code)?
I didn't downvote you, but I suspect combining PRs with issues is what most people have an issue with. Issues obviously help to improve software, but only through the fixing or writing of new code.
Maybe I'm in the minority, but I also think that if it were a requirement to never close source your project after it's already been open sourced, we'd have far fewer projects available that are open source. Often a project is created on a company's dime, and open source, to draw attention to the developer skills and ability to solve a problem. If the code was legally disallowed to be close sourced in the future, we might see far less code available universally. A working repository of code is potentially a reference for another developer to learn something new. I don't have any examples, but I know for a fact that I've read code that had been open source, and later close sourced, and learned something from the open source version (even if it was out of date for the latest libraries/platform).
> The original maintainers are gone, and users will have to rely on someone else to pick up the work,
That’s a risk that no license, open source or not, can protect against. Priorities may change, causing maintainers to stop maintaining, or maintainers (companies or people) may cease to exist.
OSS licenses also do not promise that development will continue forever, will continue in a direction you like or anything like that.
The only thing open source licenses say is “here’s a specific set of source code that you can use under these limitations”. The expectation that there will be maintenance is a matter of trust that you may or may not have in the developers.
> or maintain it themselves.
With open source, at least you have that option.
> And are you not familiar with the concept of OSS rugpulls? It's when a company uses OSS as a marketing tool, and when they deem it's not profitable enough, they start cutting corners, prioritizing their commercial product, or, as in this case, shut down the OSS project altogether.
Companies have to live. It’s not nice if something like that happen to you for a tool you depend on, but you can’t deny companies to stop doing development altogether.
In this case, you have something better, as, in addition to picking up maintenance on the existing open source version, you have the choice to pay for a version maintained by the original developers.
“Open core” is when part of the product is open-source and part is private.
Was a significant part of the product private before this announcement?
If not, someone can fork the repo and immediately launch a competitor (FOSS or paid). (Technically even if so, except it wouldn’t be immediate, and if they’d have to re-implement too much, it would be easier to start from scratch.)
Yes there were significant portions that were proprietary before this, including support for some services.
The parts that were open source might still be worth forking, but you would probably need to change every occurrence of the name to avoid trademark issues.
That's nice, although the rest of the funding felt more like helping them bootstrap their company. At least Python is going to get a bit of that money...
I evangelized localstack at my company a while back, but as we integrated it deeper into our CI test runs we started running into more and more things they don't support, and it feels impossible to get any attention from their support/devs despite being paying customers.
Their Cloud Pod and ephemeral instance features in particular feel pretty half-baked and not very useful at the moment.
Fun tangent: it's pretty easy to write a crack for the pro version; we actually used that for about a month as a pilot to confirm that it would do what we needed it to.
I too was excited about the idea originally but then started realizing that they will have an increasingly untenable service area to try and maintain and mimic and it was just never going to work out.
Yeah I remember looking at it when I started a job that was all in on AWS and quickly realised that it would be much better to just stick with real AWS and minimise my dependence on niche services.
It does seem like LLMs might make that a real proposition; of course, after these commercial enterprises steal copyright, copyleft and open source code, and the tooling gets good enough to download their cars, a new legion of DMCA lawyers and lobbies will be unleashed.
Prep yourself though for that napster bloom, it'll be here shortly.
Which services weren't supported in your use case? Currently with our enterprise contract we use all the usual suspects:
AppConfig, DynamoDB, ElastiCache, Kinesis streams, RDS/Aurora with innodb engine, S3, SecretsManager, SNS, and SQS. I'm probably forgetting a few, but we haven't hit anything unsupported (yet.)
I also haven't touched any pod stuff and have no plans to. Probably just luck of the draw we didn't hit any holes or issues, but we tend not to use any esoteric features in AWS land.
First minio and then localstack, as an open source maintainer I find that abandoning their community is bad faith. I totally get wanting to monetize but removing the free product entirely feels like such a betrayel.
Luckily, I've been vibing with Devin since this started having it build a cleanbox emulator on top of real s3 tuned for my specific use case. It's a lot less general but it's much faster and easy to add the sort of assertions I need in it. It's no localstack but for my limited use case it works.
It does feel like a betrayal. We live in a world where money is the main thing that matters and it's increasingly hard to come by and you need increasingly more of it (these are all designed policies, not emergent behavior). It makes sense that people don't want to do things for free unless they already have enough money.
Engineers who remained apolitical are now surprised the politics is bad.
Personally I think we should at least discuss changing this system into something that is more sustainable. Money is main thing, because it was decided that private property is more important than people. People like Joseph Stiglitz show that there's no such a thing as an invisible hand, even though he still believes in free market.
Yeah these moves will gain them a year or so but all these companies built on a "takes time to implement library" are all dead in the water. Localstack has nothing fancy, it just takes time to build. And that moat is gone, it's maybe 4 weekends of token quotas I wouldn't use anyway.
I never understood why AWS doesn't provide something like LocalStack out of the box.
Any team building serious software on AWS needs to mock AWS services in their CI/CD pipelines. What exactly are they expecting developers to do? They would probably argue something like "spin up real infrastructure so you are as close to production as possible" because this way they could make even more money while also avoiding the implementation / maintenance cost of the mocks.
That doesn't make sense. You use AWS services because they are in the cloud, not because you want to do self-hosting. Similar to Cloudflare wrangler, localstack should be just a well-built local mocking service.
If you're a cost-conscious startup, you could use AWS Local Thingie to run it on a 5€/month VPS while you validate your idea.
Then if you get actual customers you could move it to proper AWS - or you might find out that Fake-AWS is actually enough for you and a 20€ VPS is enough for your uses and pay 0€ to Amazon, while still filing bug tickets to AWS Local Thingie Github for bugs and feature requests =)
More reason to run your infrastructure using open source software in your own datacenter. OpenStack has been around for closing in on two decades, running clouds and being mostly governance-drama-free.
It's not surprising that a proprietary ecosystem built on open source software locked up behind a gate doesn't make a worthwhile ecosystem for building open source tooling against.
Running OpenStack for this is a massive project cost compared to spinning up a few local services, and the operational mess is on a different planet from "I need to fake a handful of API calls on my laptop". Self-hosting still means updates, drivers, and k8s/OpenStack glue code. Nobody sane are doing that for local dev, use Minikube or Podman if you want DIY and still like weekends.
I'm saying not that OpenStack can replace LocalStack, but instead that LocalStack, by building a project on top of proprietary APIs, set themselves up to fail.
This is true, sadly -- but the documentation exists and community is friendly to those who wanna build those skills. It's extremely difficult to build something the size of OpenStack without making it so configurable that operating it needs a decoder ring. I'm doing everything I can in Ironic to make it more friendly and flexible out of the box, but it's a difficult problem to solve.
I always tell people: OpenStack can do almost anything you want... if you can configure it to do so :).
There's a reason I point out the longevity of OpenStack. As a project, it has significant corporate sponsorship and policies to ensure that one entity can't take over control of it. For instance; the OpenStack Technical Committee is never permitted to have a majority membership made up of a single entity's employees. This means that even though Red Hat, at this stage in it's development, has a majority of contribution, the project itself can never be taken over by a single entity.
People find project governance, and particularly "corporate" involvement in open source to be distasteful -- but in my experience, and OpenStack is a winning example of this -- setting up good boundaries to let companies work together has proven to be sustainable.
> This means that even though Red Hat, at this stage in it's development, has a majority of contribution, the project itself can never be taken over by a single entity.
If it's one company with the majority of contributions then they can just stop contributing (or put their efforts into a proprietary fork) and all that you're left with is the code and the name. Which is maybe better than "just the code", but not by much.
There are over 600 different people contributing to OpenStack in a given six-month release cycle. Approximately 60% of total code by commit count is from Red Hat employees. I'm one of the 600 that don't work at Red Hat, and there are a lot of us.
You should get a sense of the scale of a project before summarily declaring that it has a single point of failure.
You just said majority without any numbers in the original post. I think you'll agree that the calculus would be quite different for 60% vs 85% of effort being from a single company.
I always found it odd that the marketing successfully pivoted the term Cloud Native from meaning 'managed services consumed as APIs over the internet' to a generic umbrella for self-hosted versions of the cloud control planes and container management tooling.
That isn't a dig at the particular tools themselves - they just aren't... you know... cloud.
K8s mostly provides that layer. What’s missing is for cloud providers to implement all their services as k8s resources. Many already are, like all the networking stuff, VMs, storage and loadbalancers. I think it’s missing things like an object or kv store, sql databases, etc. won’t be surprised if they eventually make their way there. But like everything complicated, you’ll end up with people taking dependence’s on various vendor specific behaviors or features.
f you were trying to unify cloud providers existing manages services and consume them as APIs over the internet, you would begin by defining what that API is, not adopt an existing vendor API. And that’s what k8s did.
Perhaps we should stop running things on clouds to begin with. Localstack's main point was that AWS cannot be run locally. Nobody seems to have a problem with that here, which is the bigger problem.
I worked for a company that also used AWS. It was a cloud-first company so we needed to use AWS stuff even if there was a more portable variant available. We needed to run this Localstack to get stuff done. I really did not like using localstack.
They were, but they moved off them - probably with a move away from OSS as a long term plan.
I've used Localstack extensively for ~7 years, and I will rejoice when I can finally be free of it. I've found it to be low quality software, and full of bugs.
In my first few hours:
- it failed with Pekko due to not returning version information properly
- it doesn't support range requests in S3 (!)
This project is 8 days old. It did support most of my workflow, but ... I don't get the warmest of fuzzies relying on something so brand new. But here we are in the age of vibe coded AI replacements, what a time to be alive.
For S3 emulation, I'm using rustfs. It's very compact and fast to run, and you can just start it with `docker run` inside tests if you don't want to set up a full integration test harness.
I used an SQS-on-top-of-Redis emulation before, but I can't recommended it now (no updates for 6 years).
It didn't support the one thing I wanted but it was so easy to find the right place in the code, I was happy. Never got to continue it though or turn it into a PR
Complete coincidence but today I was looking for an AWS mock for E2E tests. Not the whole AWS footprint but just a few services and looked at LocalStack for the first time.
It took Claude to put together a service (with web interface and everything) for those 2 services 15 mins.
I’m not claiming my experience is translated universally but perhaps if your core competency is something like LocalStack you need to think about alternative business ideas.
Well LLMs are trained on code like those from Localstack, and a lot of them can be emulated to first order as CRUD operations, so its rather unsurprising. It does mean that things do become difficult for pure tech SaaS businesses like this one, and as also seen with Tailwind.
I have been working with AWS for almost a decade on professionally and never saw a reason not just to run test and develop in a real isolated AWS account with security policies (guardrails) and give out accounts with budget alerts.
We all have personal AWS environments and use them as need arises at my org. Doesn't stop the fact cloudformation deployments take inordinate amounts of time for seemingly no reason. Basic shit like pushing a new ECS task takes 10+ minutes alone. Need to push an IAM policy change by itself? 5 minutes. Maybe it's the CDK, but we've only been on that a couple years, prior we used a ansible and cloudformation templates directly but it wasn't any better. This compounds with each dev and each change across multiple stacks. Not only that cloudformation easily gets "stuck" in unrecoverable states when rollback fails and you have to manually clean up to clean up drift which can easily eat your entire day. I'll note that our stacks have good separation by concerns, doesn't matter. A full deployment of a single ECS service easily takes 30 minutes. This is so wasteful it's absurd. I'd love to NOT have to use a shim like LocalStack but the alternative is what?
It’s never taken 30 minutes to pass in a new parameter value for the Docker container.
Also as far as rollbacks just use —disable-rollbacks.
The only time I’ve had CFT get stuck is using custom resources when I didn’t have proper error handling and I didn’t send the failure signal back to CFT.
Failed deployments without rollbacks still leave you in a unusable state and manual rollbacks of a failed service deployment can take as long to cleanup as the failed rollback you just disabled especially when dealing with persistent resources. That linked fargate stack is fairly bare bones in comparison to what we run in ECS and we maintain our own AMIs that are built nightly for security updates and ECR resources from docker build pipelines which need to go together in a real AWS environment to have any hope of actually working. A failure in one has cascading effects on others and cleanup is a pain. Passing a new parameter isn't a real exercise and we need a new docker build with every code change. Glad you have a minimalist setup and can get by with what? 10m deployments end to end? Sadly that's not the world I live in...
Why are you running your own AMIs for ECS instead of just using Fargate?
The build pipeline I used in CodeBuild was build the Docker container and a sidecar Nginx container.
The parameter you pass in is the new Docker container you just built.
But how would LocalStack help?
You also don’t have massive CDK apps. The Docker images are going to change much more frequently than your persistent layer. You’re not going to be bringing up and down your VPCs, database clusters etc.
Own AMIs? Simply cost. No other reason, although we're evaluating it again, so we'll see.
We actually have several "massive" CDK projects now, depending on what metric you use for determining size. Our largest CDK app has more than 60 stacks, but with a cellular architecture that's artifially inflating the numbers a bit (n unique stacks against k AWS accounts where k > n but for n > 20, < 100) Maybe the speed at which we change persistent layers (99% additive) will slow down someday, but when you maintain a large number of services (>14) with constantly changing external contracts, it probably won't; it hasn't the last 6 years, it only gets faster.
There's going to be a lot of complaints about open-source restricting access.
It's going to keep happening because it just doesn't make sense for a lot of previous business models that supported and open-source project, something that was seen recently with tailwind.
In one of my projects, one that remains source-available, I had encountered an "open-source justice warrior" that made it their mission to smear the project because of the switch, grasping at straws to do everything they could to paint my intentions as malicious.
It's really too bad, and will only hurt the availability of free alternatives if one cannot provide the source under a "just don't commercially compete with the paid version of the product" license without getting branded as a scamming cash grabber
Source available with various arbitrary restriction is non-free software. What the "open source warriors" take exception to is presenting a project as "open source" or "free" when in reality it is not.
A thing cannot be considered free/open source if there are restrictions on what users can do with it. If a maintainer wishes to put a "don't compete commercially" license then it should be clearly labelled as source available, not open source. To do otherwise is to deceive the open source community, which has a particular and well defined understanding of what "open source" entails.
> 6. No Discrimination Against Fields of Endeavor
>
> The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
A non-commercial clause is a discrimination against a field of endeavor and thus non-open-source. The license cannot restrict how the user is able to *use* the software and still be open source. There can however be requirements to distribute the source code when distributing the software, ala GPL.
My main complaint about the project changes we've seen lately is that these companies are happy to take all the code that previous contributors have written for free in good faith, and profit off of it without any sharing. The whole reason I and many people have contributed to some of the projects out there is under the premise that I've been given something great/useful for free so I'm going to give back for free. If you want to create a project that's source-available or whatever you want to call it, from the start, you'll probably even get my support.
Sure, it's totally legal for the company to change how they operate in the future. But it burns all that good faith of previous contributions in favor of profit. And so yeah, I hope the companies that pull this crash and burn in proportion to how much free code they accepted from contributors that they now wish to profit from.
IMO, the trajectory was set back when they removed the option for monthly payments. Minimum US$450 to play made it a non-starter for my projects (even with commercial ambitions). They changed this just as I started to integrate (~2024, I think) so I kept to the free capabilities. Have been waiting for the other show to drop and here we are.
Edit: looks like they’ve reintroduced monthly billing within the last few months. I guess that’s a sort of win, even if not for the OSS community. But I’d still be reluctant to get into bed with them at this stage.
That solution can be recreated by a skilled AI boosted senior platform engineer in a few days and parity achieved in a few weeks. Nothing of value was lost.
They still have linked their OpenCollective account, where they have raised $10K and still have a balance of $5K. [0]
It's not a lot in the great scheme of things, but, have they been using a platform that's seemingly built for communities and open source to bootstrap their business?
Because this is not a 'open core' situation. They just closed the repo and ran away. If they had that idea all along, I feel like it hasn't be very, let's say, ethical.
--
Wait, so a company shared their work with the public for however long, then decided to leave what was shared up ... but stop sharing ... and you're upset?!?
They did everything properly by the rules of OSS, decided it wasn't in their best interest to keep doing OSS, and left all their code available, as required by OSS. They were a textbook good participant.
Meanwhile, 99% of companies never open source anything: why aren't you complaining about how "unethical" they are?
> and left all their code available, as required by OSS.
IANAL, and I don't have a horse in this race, but I don't think that's required by OSS, not by the spirit of "the law", and (at least) not by GPL, MIT, and other similar mainstream licenses.
The spirit of open source is: you buy (or just download for free) a binary, you get the 4 rights. Whatever happens when the developer/company stops distributing (whether at a cost or free as in beer) that binary is completely outside the scope of the license.
You only have the right to modify if you can access the source.
If you got (a snapshot of) the source along with the binary, that's fine, there's no need to keep hosting the source anywhere.
But if the company said "for source, see: our github", then that github has to stay up/public, for all the people who downloaded the binary a long time ago and are only getting around to exercising their right to modify today.
They don't need to post new versions of their software to it, of course. But they need to continue to make the source available somehow to people who were granted a right that can only be exercised if the source is made available to them.
(IIRC, some very early versions of this required you to send a physical letter to the company to get a copy of the source back on CD. That would be fine too. But they'd also have to advertise this somewhere, e.g. by stubbing the github repo and replacing it with a note that you can do that.)
In GPL, it has to be valid for 3 years, but only if they're not the copyright holder.
In MIT, a.k.a. "the fuck you license" there is no requirement and they don't even have to give you source code at all.
> a company shared their work with the public for however long, then decided to leave what was shared up
More like a company took advantage of a community that expected their freely offered labor to not be commercialized at any point in time without making available said works in a fully free vector as well, as that's an implicit expectation behind "open source".
> … took advantage of a community…
It would be helpful for everyone if that community would pause before contributing to code bases with licenses which allow for that. MIT, BSD, Apache, …
It would be helpful for them because they’ll know what they’re getting into. For us because we won’t have to see this tragedy unfold time and time again. And for all open source users because more efforts will be directed towards programs with licenses that protect end users. GPL, AGPL, …
It will be a little worse for companies seeking free labor. A price I’m willing to pay.
It looks like it's Apache licensed, so this was the expected and intended outcome for contributors. If they wanted their work to remain free and not become proprietary, they should have only contributed under perma-free licenses like GPL.
The GPL protects against this.
Donating software to the world is not an expectation that nobody uses that software to make money or build proprietary products on top of it.
Not all f/oss contributors are anticapitalist zealots like the FSF, as evidenced by the huge popularity of permissive licenses such as MIT.
There’s nothing implicit about it. The licenses are explicit legal documents.
> anticapitalist zealots like the FSF
In what way are they?
'The term "free" is used in the sense of "free speech", not "free of charge"'
https://en.wikipedia.org/wiki/The_Free_Software_Definition
Naive fools…
Companies stand to turn a profit. OSS is here to help enable that or push the goal posts. It’s not a charity unless the org feels charitable. Sure, non-profits exist but they were never one of those.
I think the comment on corpos is good, but calling the naive people fools might be unnecessary - it’s probably not their fault nobody told them about this sort of thing before and learning that lesson is probably disappointing enough already.
It’s unfortunate that this keeps happening to projects like MinIO and others too.
We should return to the HN guidelines, and read it as charitably as possible.
I'm interpreting it as closer to pity, rather than genuine criticism =)
Sure! Slightly edited the tone, but I’m noticing that often people have idealistic attitudes about FOSS until they get burnt by bad faith actors or even just indifferent corps that have to keep the lights on. Quite unfortunate, definitely not their fault. Pity is correct.
It’s definitely pity. It’s a hard pill to swallow when you were led to believe a certain world view of an entity only to find out they were milking your data.
They are going about to learn the same lesson Elastic learned with OpenSearch...
I can't think of any free or open license that requires you to leave your code available for any specific period of time if you are not simultaneously distributing binaries.
Because this thread isn't about those other companies.
How can people still not understand that OSS can be abused?
It doesn't matter that the previous code is still available. Nobody can technically delete it from the internet, so that's hardly something they did "right".
The original maintainers are gone, and users will have to rely on someone else to pick up the work, or maintain it themselves. All of this creates friction, and fragments the community.
And are you not familiar with the concept of OSS rugpulls? It's when a company uses OSS as a marketing tool, and when they deem it's not profitable enough, they start cutting corners, prioritizing their commercial product, or, as in this case, shut down the OSS project altogether. None of this is being a "textbook good participant".
> Meanwhile, 99% of companies never open source anything: why aren't you complaining about how "unethical" they are?
Frankly, there are many companies with proprietary products that behave more ethically and have more respect for their users than this. The fact that a project is released as OSS doesn't make it inherently better. Seeing OSS as a "free gift" is a terrible way of looking at it.
> It doesn't matter that the previous code is still available…The original maintainers are gone, and users will have to rely on someone else to pick up the work, or maintain it themselves.
It does matter: popular products have been forked or the open-source component was reused. E.g. Terraform and OpenTofu, Redis and Redict, Docker and Colima (partly MinIO and RustFS; the latter is a full rewrite, but since the former was FOSS and it’s a “drop-in binary replacement”, I’m sure they looked at the code for reference…)
If your environment doesn’t have API changes and vulnerabilities, forking requires practically zero effort. If it does, the alternative to maintaining yourself or convincing someone to maintain it for you (e.g. with donations), is having the original maintainers keep working for free.
Although this specific product may be mostly closed source (they’ve had commercial addons before the announcement). If so, the problem here is thinking it was open in the first place.
To be clear, colima isn't a fork of docker. It's just the lima VM with the docker OCI runtime + cli which is FOSS and always has been. Docker Desktop is the pile of garbage you can kinda sorta replace it with, but PodMan and PodMan Desktop is closer to a clone of Docker than Colima. Colima _is_ Docker
I thought Valkey was the blessed fork of Redis. Is Redict better in some way?
No
https://en.wikipedia.org/wiki/Cognitive_dissonance
You might want to get your arguments in order. In one sentence you're calling OSS rugpulls a problem, and then in another you're claiming that proprietary products behave more ethically.
So which is it? Is it less-ethical to have provided software as open source, and then later become a proprietary product? Why? I see having source code, even for an old/unmaintained product be strictly superior to having never provided the source code no matter how much "respect" the company has for their users today.
You might want to think about my argument a bit more.
> Is it less-ethical to have provided software as open source, and then later become a proprietary product? Why?
Because usually these companies use OSS as a marketing gimmick, not because they believe in it, or want to contribute to a public good. So, yes, this dishonesty is user hostile, and some companies with proprietary products do have more respect for their users. The freedoms provided by free software are a value add on top of essential values that any developer/company should have for the users of their software. OSS projects are not inherently better simply because the code is free to use, share, and modify.
To be fair, I don't think a developer/company should be expected to maintain an OSS project indefinitely. Priorities change, life happens. But being a good OSS steward means making this transition gradually, trying to find a new maintainer, etc., to avoid impacting your existing user base. Archiving the project and demanding payment is the epitome of hostile behavior.
It seems like you’re trying to build a system of ethics around being annoyed by OSS maintainers not working for free in perpetuity.
Having access to Apache licensed code that you can build off of is better than never having access to any code at all. Anything else about values or respect has to be inferred or imagined and has no bearing on the software itself.
Edit: Like who cares if they “wanted” to contribute to the public good? Did they actually contribute to the public good? It seems like they did and the code that did so is right there. If “life happens” then why are they obligated to do a smooth transition?
I love free stuff as much as the next person, hell, free stuff is my favorite kind of stuff. Is it annoying when there’s less free stuff? Yes. Does my personal irritation constitute a violation of a lofty set of ideals that just coincidentally dictates that nobody annoy me? No.
I would love to live in a world where it just so happens that it’s ethically wrong to bother me though. That would be sweet.
That's what they always do it always comes down to a sense of perpetual entitlement over the work of others, work they themselves would never do.
I've had the same discussion for years now on HN. It is not unethical to decide to stop supporting something especially if you played by all the rules the entire time.
No one is owed perpetual labor and they completely disregard localstack has been oss for something like 10 years at this point just celebrate it had a good run, fork and maintain yourself if you need it that badly.
It is incredibly weird to think something that was maintained oss for 10 years is a rugpull that's just called life, circumstances change.
> I've had the same discussion for years now on HN. It is not unethical to decide to stop supporting something especially if you played by all the rules the entire time.
What's unethical is taking yhe fruits of other people's work private: ranging from code contributions, through bug reports and evangelism.
Companies are never honest about how they intend to use CLAs and pretend its for the furtherance of open source ethos. Thankfully, there's an innate right to fork entire projects after rug pulls, whixh makes them calculated gambles amd nor a quick heist.
> What's unethical is taking yhe fruits of other people's work private: ranging from code contributions, through bug reports and evangelism.
First, if it's open source, then the contributions are still there for everyone to use.
Second, if the license allows it, then the license allows it.
Now, if the contributions were made with a contribution license to prevent it, you've got a solid argument. Otherwise you're applying your own morals in a situation where they're irrelevant.
I agree, along with the child comment. I think the issue is that if there wasn't some kind of ability to "rug pull," that we would see far fewer open source contributions in the first place.
I hate that a company can take a fully open-source project, and then turn it into a commercial offering, dropping support for the project's open source model. I am fine with a project's maintainers stopping support for a project because they have other things to deal with, or just are burnt out. I understand that both of these things are allowed under the specific license you choose, and still believe you should have the freedom to do what was done here (although not agreeing with the idea of what was done, I still think it should be allowed). If you want to guarantee your code is allowed to live on as fully open, you pick that license. If you don't, but want to contribute as a means to selling your talent, I still think the world would have far less software if this was discouraged. The source is still legal from before the license was changed, and I feel that even if the project doesn't get forked, it is still there for others to learn from.
With that said I'm wondering if there has ever been a legal case where source was previously fully open source, then became closed source, and someone was taken to court over using portions of the code that was previously open. It seems like it would be cut and dry about the case being thrown out, but what if the code was referenced, and then rewritten? What if there was code in the open source version that obviously needed to be rewritten, but the authors closed the source, and then someone did the obvious rewrite? This is more of a thought experiment than anything, but I wonder if there's any precedent for this, or if you'd just have to put up the money for attorneys to prove that it was an obvious change?
> Second, if the license allows it, then the license allows it.
I'm not arguing the legality. One can be a jerk while complying with the letter of the license.
I stopped signing CLAs, and I feel bad for those suckered into signing CLAs - based on a deliberate lie that they are joining a "community" - when the rug pull is inevitably attempted. I hate that "open source as a growth hack" have metastisized onto rug pull long cons.
> Otherwise you're applying your own morals in a situation where they're irrelevant.
Sharing my opinion on an HN thread about an open source rug-pull is extremely relevant.
The ethical problem is the bait-and-switch. A project that begins open and remains open is no problem; a project that begins closed and remains closed is no problem (ethically); a project that begins closed and becomes open is no ethical problem either. But a project that begins open, advertises their openness to the world, uses their openness to attract lots of community interest and then suddenly becomes closed is pulling a bait-and-switch, or rugpull.
> a project that begins open, advertises their openness to the world, uses their openness to attract lots of community interest and then suddenly becomes closed
Do you have any examples of that happening? When I click on the link at the top of this thread it takes me to a GitHub repo with a bunch of Apache licensed code that is open to anyone that wants to use or modify or build off of however they want. Heck, with permissive licensing like that you or I could fork it and put any part/all of that code into a proprietary product and make money off of it if we wanted to, and that would be entirely in keeping with the spirit and practice of FOSS.
This project seems perfectly open from what I can see, looks like the original devs stopped working on it though
Precisely.
It's remarkable that people think releasing a project as OSS is a license to disrespect users. This isn't even related to OSS. Software authors should have basic decency and respect for the users of their software. This relationship starts with that.
Publishing a project as OSS doesn't relinquish you from this responsibility. It doesn't give you the right to be an asshole.
And yet we fall for this trap time and time again, and there are always those who somehow defend this behavior.
I think it's an inherent conflict with the entrepreneurship mindset and those who visit this forum. Their primary goal is to profit from software. OSS is seen as a "gift" and an act of philanthropy, rather than a social movement to collaborate on building public goods. That's silly communism, after all. I'm demanding that people work for free for my benefit! Unbelievable.
Wow.
"Software authors should have basic decency and respect for the users of their software." Why? Not at all.
"Publishing a project as OSS doesn't relinquish you from this responsibility. It doesn't give you the right to be an asshole." You are free to be asshole and it's nobody's business.
Actually it's exactly opposite. Such feeling of superiority and privilege, that just because you use some software, you have any right to command its author is the very definition of being an asshole.
"I'm demanding that people work for free for my benefit! Unbelievable." Yes, that's unbelievable.
> "Software authors should have basic decency and respect for the users of their software." Why? Not at all.
Because that's the core reason why we build software in the first place. We solve problems for people. Software doesn't exist in a void. There's an inherent relationship created between software authors and its users. This exists for any good software, at least. If you think software accomplishes its purpose by just being published, regardless of its license, you've failed at the most fundamental principle of software development.
> you have any right to command its author is the very definition of being an asshole.
Hah. I'm not "commanding" anyone anything. I'm simply calling out asshole behavior. The fact is that software from authors who behave like this rarely amounts to anything. It either dies in obscurity, or is picked up by someone who does care about their users.
> "I'm demanding that people work for free for my benefit! Unbelievable." Yes, that's unbelievable.
Clearly sarcasm goes over your head, since I'm mimicking what you and others think I'm saying. But feel free to continue to think I'm coming from a place of moral superiority and privilege.
If you want software to be free for everyone except for the authors to use, modify, distribute, and sell without restriction I am sure you could work with a lawyer to draft a new “Apache for everybody on earth other than the maintainers, who permanently waive all rights” license.
If that’s what all good maintainers do, and intend to do, there’s really no reason for maintainers to tempt themselves by using awful “open” licenses that allow them the loophole of doing what they want with the software they create. Plus who wouldn’t want to codify that they’re not an asshole?
It shouldn’t be hard to get maintainers that intend for their software to “amount to something” to adopt it, and it would bring a sense of comfort to the people that rely on the software that you write when you announce that it’s the new default license for everything in your repos.
I have no idea what you're talking about.
Your argument is about some sort of covenant between the developers/maintainers and the users. That’s what a license is. That is the agreement between the parties. In that sense your problem isn’t with individual developers, it’s with permissive licensing.
If you don’t like it when OSS maintainers pivot to proprietary software, why not just create a license that precludes that from happening? The maintainers could waive their rights to pivot or later reuse the code that they wrote in any proprietary software, and that way people could just choose to only create and use NoRugPullForeverEver-licensed software and avoid the headaches altogether.
It's a matter of honesty and trust. A company that has never provided source code is more honest and trustworthy than one that provides source code, extracts community labor (by accepting issues and/or PRs) and then makes off with said labor (even if they left a frozen version available) at a future point.
Does the amount of labor that was provided by a community make a difference? What if it was minimal? Where do you draw the line (any piece of code accepted, or a "large portion" of code)?
I didn't downvote you, but I suspect combining PRs with issues is what most people have an issue with. Issues obviously help to improve software, but only through the fixing or writing of new code.
Maybe I'm in the minority, but I also think that if it were a requirement to never close source your project after it's already been open sourced, we'd have far fewer projects available that are open source. Often a project is created on a company's dime, and open source, to draw attention to the developer skills and ability to solve a problem. If the code was legally disallowed to be close sourced in the future, we might see far less code available universally. A working repository of code is potentially a reference for another developer to learn something new. I don't have any examples, but I know for a fact that I've read code that had been open source, and later close sourced, and learned something from the open source version (even if it was out of date for the latest libraries/platform).
Open Source Software doesn't mean maintenance free.
The code is all there mate.
Their time and efforts and ongoing contributions to the project are not.
OSS is not about fairness and free work from people. It's just putting the code out there in public.
> The original maintainers are gone, and users will have to rely on someone else to pick up the work,
That’s a risk that no license, open source or not, can protect against. Priorities may change, causing maintainers to stop maintaining, or maintainers (companies or people) may cease to exist.
OSS licenses also do not promise that development will continue forever, will continue in a direction you like or anything like that.
The only thing open source licenses say is “here’s a specific set of source code that you can use under these limitations”. The expectation that there will be maintenance is a matter of trust that you may or may not have in the developers.
> or maintain it themselves.
With open source, at least you have that option.
> And are you not familiar with the concept of OSS rugpulls? It's when a company uses OSS as a marketing tool, and when they deem it's not profitable enough, they start cutting corners, prioritizing their commercial product, or, as in this case, shut down the OSS project altogether.
Companies have to live. It’s not nice if something like that happen to you for a tool you depend on, but you can’t deny companies to stop doing development altogether.
In this case, you have something better, as, in addition to picking up maintenance on the existing open source version, you have the choice to pay for a version maintained by the original developers.
So basically businesses should go bankrupt because making money is "unethical"
“Open core” is when part of the product is open-source and part is private.
Was a significant part of the product private before this announcement?
If not, someone can fork the repo and immediately launch a competitor (FOSS or paid). (Technically even if so, except it wouldn’t be immediate, and if they’d have to re-implement too much, it would be easier to start from scratch.)
Yes there were significant portions that were proprietary before this, including support for some services.
The parts that were open source might still be worth forking, but you would probably need to change every occurrence of the name to avoid trademark issues.
yes, there were a large number of AWS products and features that were only available with a subscription
https://opencollective.com/oc-python-fund/contributions/9388...
That's nice, although the rest of the funding felt more like helping them bootstrap their company. At least Python is going to get a bit of that money...
Just because you don't like it doesn't make it "unethical".
Its JBoss again....
I evangelized localstack at my company a while back, but as we integrated it deeper into our CI test runs we started running into more and more things they don't support, and it feels impossible to get any attention from their support/devs despite being paying customers.
Their Cloud Pod and ephemeral instance features in particular feel pretty half-baked and not very useful at the moment.
Fun tangent: it's pretty easy to write a crack for the pro version; we actually used that for about a month as a pilot to confirm that it would do what we needed it to.
I used some small parts of localstack a long time back for some integration tests. I haven't kept up with what it does.
Looking at their pricing tiers, it seems that their paid product now a cloud based service, or partly cloud based.
I don't really see why you would pay to use a cloud based AWS emulator, instead of just using a real AWS account.
I too was excited about the idea originally but then started realizing that they will have an increasingly untenable service area to try and maintain and mimic and it was just never going to work out.
Yeah I remember looking at it when I started a job that was all in on AWS and quickly realised that it would be much better to just stick with real AWS and minimise my dependence on niche services.
It does seem like LLMs might make that a real proposition; of course, after these commercial enterprises steal copyright, copyleft and open source code, and the tooling gets good enough to download their cars, a new legion of DMCA lawyers and lobbies will be unleashed.
Prep yourself though for that napster bloom, it'll be here shortly.
Agree but still a lot of surface area
Which services weren't supported in your use case? Currently with our enterprise contract we use all the usual suspects:
AppConfig, DynamoDB, ElastiCache, Kinesis streams, RDS/Aurora with innodb engine, S3, SecretsManager, SNS, and SQS. I'm probably forgetting a few, but we haven't hit anything unsupported (yet.)
I also haven't touched any pod stuff and have no plans to. Probably just luck of the draw we didn't hit any holes or issues, but we tend not to use any esoteric features in AWS land.
[dead]
First minio and then localstack, as an open source maintainer I find that abandoning their community is bad faith. I totally get wanting to monetize but removing the free product entirely feels like such a betrayel.
Luckily, I've been vibing with Devin since this started having it build a cleanbox emulator on top of real s3 tuned for my specific use case. It's a lot less general but it's much faster and easy to add the sort of assertions I need in it. It's no localstack but for my limited use case it works.
It does feel like a betrayal. We live in a world where money is the main thing that matters and it's increasingly hard to come by and you need increasingly more of it (these are all designed policies, not emergent behavior). It makes sense that people don't want to do things for free unless they already have enough money.
Engineers who remained apolitical are now surprised the politics is bad.
Personally I think we should at least discuss changing this system into something that is more sustainable. Money is main thing, because it was decided that private property is more important than people. People like Joseph Stiglitz show that there's no such a thing as an invisible hand, even though he still believes in free market.
Yeah these moves will gain them a year or so but all these companies built on a "takes time to implement library" are all dead in the water. Localstack has nothing fancy, it just takes time to build. And that moat is gone, it's maybe 4 weekends of token quotas I wouldn't use anyway.
> I totally get wanting to monetize
Yup, unfortunately people need to eat.
I never understood why AWS doesn't provide something like LocalStack out of the box. Any team building serious software on AWS needs to mock AWS services in their CI/CD pipelines. What exactly are they expecting developers to do? They would probably argue something like "spin up real infrastructure so you are as close to production as possible" because this way they could make even more money while also avoiding the implementation / maintenance cost of the mocks.
My general principle has been “don’t build what you can’t test locally”. It seems so obvious but PaaS does challenge it.
It also has the benefit of steering clear of exotic proprietary features that are hard to migrate between providers.
Local stack formed a big part of making that principle realistic.
(EDIT - but I can see how that's counter to AWS' interests! It's desirable that they provide it, but not surprising that they don't.)
For a subset of people the AWS version of localstack would be enough to run production loads. Which is bad for business =)
That doesn't make sense. You use AWS services because they are in the cloud, not because you want to do self-hosting. Similar to Cloudflare wrangler, localstack should be just a well-built local mocking service.
There's still a cost.
If you're a cost-conscious startup, you could use AWS Local Thingie to run it on a 5€/month VPS while you validate your idea.
Then if you get actual customers you could move it to proper AWS - or you might find out that Fake-AWS is actually enough for you and a 20€ VPS is enough for your uses and pay 0€ to Amazon, while still filing bug tickets to AWS Local Thingie Github for bugs and feature requests =)
[dead]
More reason to run your infrastructure using open source software in your own datacenter. OpenStack has been around for closing in on two decades, running clouds and being mostly governance-drama-free.
It's not surprising that a proprietary ecosystem built on open source software locked up behind a gate doesn't make a worthwhile ecosystem for building open source tooling against.
Running OpenStack for this is a massive project cost compared to spinning up a few local services, and the operational mess is on a different planet from "I need to fake a handful of API calls on my laptop". Self-hosting still means updates, drivers, and k8s/OpenStack glue code. Nobody sane are doing that for local dev, use Minikube or Podman if you want DIY and still like weekends.
I'm saying not that OpenStack can replace LocalStack, but instead that LocalStack, by building a project on top of proprietary APIs, set themselves up to fail.
LocalStack built a mock of proprietary APIs, not on top. There's a distinct difference.
OpenStack is one of the most complicated platforms in existence and finding suitably talented admins is very hard.
This is true, sadly -- but the documentation exists and community is friendly to those who wanna build those skills. It's extremely difficult to build something the size of OpenStack without making it so configurable that operating it needs a decoder ring. I'm doing everything I can in Ironic to make it more friendly and flexible out of the box, but it's a difficult problem to solve.
I always tell people: OpenStack can do almost anything you want... if you can configure it to do so :).
> More reason to run your infrastructure using open source software in your own datacenter
Until they stop being open source. Like, you know, LocalStack.
There's a reason I point out the longevity of OpenStack. As a project, it has significant corporate sponsorship and policies to ensure that one entity can't take over control of it. For instance; the OpenStack Technical Committee is never permitted to have a majority membership made up of a single entity's employees. This means that even though Red Hat, at this stage in it's development, has a majority of contribution, the project itself can never be taken over by a single entity.
People find project governance, and particularly "corporate" involvement in open source to be distasteful -- but in my experience, and OpenStack is a winning example of this -- setting up good boundaries to let companies work together has proven to be sustainable.
> This means that even though Red Hat, at this stage in it's development, has a majority of contribution, the project itself can never be taken over by a single entity.
If it's one company with the majority of contributions then they can just stop contributing (or put their efforts into a proprietary fork) and all that you're left with is the code and the name. Which is maybe better than "just the code", but not by much.
There are over 600 different people contributing to OpenStack in a given six-month release cycle. Approximately 60% of total code by commit count is from Red Hat employees. I'm one of the 600 that don't work at Red Hat, and there are a lot of us.
You should get a sense of the scale of a project before summarily declaring that it has a single point of failure.
You just said majority without any numbers in the original post. I think you'll agree that the calculus would be quite different for 60% vs 85% of effort being from a single company.
Probably to do with the emergence of a vibe coded app that probably used their tests and code
https://github.com/hectorvent/floci
Doesn't look like it's using their code. LocalStack is Python, while floci is using Java.
Seems it's the other way around: the README cites the months older sunset announcement as the motivation.
An emulator for integration testing against the major cloud providers seems like it should:
1. be table-stakes for a SDK from the cloud providers themselves
2. have the obvious home in a foundation like the CNCF; how else could you be "cloud native" afterall?
ha. Cloud Native ≠ Native Cloud Services.
I always found it odd that the marketing successfully pivoted the term Cloud Native from meaning 'managed services consumed as APIs over the internet' to a generic umbrella for self-hosted versions of the cloud control planes and container management tooling.
That isn't a dig at the particular tools themselves - they just aren't... you know... cloud.
K8s mostly provides that layer. What’s missing is for cloud providers to implement all their services as k8s resources. Many already are, like all the networking stuff, VMs, storage and loadbalancers. I think it’s missing things like an object or kv store, sql databases, etc. won’t be surprised if they eventually make their way there. But like everything complicated, you’ll end up with people taking dependence’s on various vendor specific behaviors or features.
f you were trying to unify cloud providers existing manages services and consume them as APIs over the internet, you would begin by defining what that API is, not adopt an existing vendor API. And that’s what k8s did.
Perhaps we should stop running things on clouds to begin with. Localstack's main point was that AWS cannot be run locally. Nobody seems to have a problem with that here, which is the bigger problem.
I worked for a company that also used AWS. It was a cloud-first company so we needed to use AWS stuff even if there was a more portable variant available. We needed to run this Localstack to get stuff done. I really did not like using localstack.
What are the alternatives? I primarily used it for S3 and SQS emulation.
I haven't used this yet, but there's also https://github.com/robotocore/robotocore. It came up on HN a few days ago: https://news.ycombinator.com/item?id=47420619.
It's not a complete replacement, but if you're in a Python ecosystem, you might find Moto to be of interest.
https://github.com/getmoto/moto
at least some parts of localstack seemed to be built on moto, based on a brief look at some point
They were, but they moved off them - probably with a move away from OSS as a long term plan.
I've used Localstack extensively for ~7 years, and I will rejoice when I can finally be free of it. I've found it to be low quality software, and full of bugs.
I haven't evaluated it deeply yet, but I saw https://github.com/hectorvent/floci
In my first few hours: - it failed with Pekko due to not returning version information properly - it doesn't support range requests in S3 (!)
This project is 8 days old. It did support most of my workflow, but ... I don't get the warmest of fuzzies relying on something so brand new. But here we are in the age of vibe coded AI replacements, what a time to be alive.
For S3 emulation, I'm using rustfs. It's very compact and fast to run, and you can just start it with `docker run` inside tests if you don't want to set up a full integration test harness.
I used an SQS-on-top-of-Redis emulation before, but I can't recommended it now (no updates for 6 years).
I am about to test this one http://docs.getmoto.org/en/latest/index.html
I've fiddled around with https://docs.getmoto.org/en/latest/docs/server_mode.html
It didn't support the one thing I wanted but it was so easy to find the right place in the code, I was happy. Never got to continue it though or turn it into a PR
MinIO is a drop in replacement for S3. I plan on switching to this as soon as I can. For now, I just pinned localstack to 4.14.0
>MinIO
I have some bad news for you: https://news.ycombinator.com/item?id=47000041
It's comedic that they said that right after Minio pulled the same thing as localstack.
RustFS is a good and simple-to-usr alternative for MinIO.
> I plan on switching to this as soon as I can
Too late.
[flagged]
Complete coincidence but today I was looking for an AWS mock for E2E tests. Not the whole AWS footprint but just a few services and looked at LocalStack for the first time.
It took Claude to put together a service (with web interface and everything) for those 2 services 15 mins.
I’m not claiming my experience is translated universally but perhaps if your core competency is something like LocalStack you need to think about alternative business ideas.
Well LLMs are trained on code like those from Localstack, and a lot of them can be emulated to first order as CRUD operations, so its rather unsurprising. It does mean that things do become difficult for pure tech SaaS businesses like this one, and as also seen with Tailwind.
How do you know that Claude's moc matches the AWS API behaviour perfectly?
[flagged]
Did localstack never get bit enough that a fork would emerge or am I missing an obvious one?
I have been working with AWS for almost a decade on professionally and never saw a reason not just to run test and develop in a real isolated AWS account with security policies (guardrails) and give out accounts with budget alerts.
We all have personal AWS environments and use them as need arises at my org. Doesn't stop the fact cloudformation deployments take inordinate amounts of time for seemingly no reason. Basic shit like pushing a new ECS task takes 10+ minutes alone. Need to push an IAM policy change by itself? 5 minutes. Maybe it's the CDK, but we've only been on that a couple years, prior we used a ansible and cloudformation templates directly but it wasn't any better. This compounds with each dev and each change across multiple stacks. Not only that cloudformation easily gets "stuck" in unrecoverable states when rollback fails and you have to manually clean up to clean up drift which can easily eat your entire day. I'll note that our stacks have good separation by concerns, doesn't matter. A full deployment of a single ECS service easily takes 30 minutes. This is so wasteful it's absurd. I'd love to NOT have to use a shim like LocalStack but the alternative is what?
I have been using a modified version of this for 8 years. I didn’t write it
https://github.com/1Strategy/fargate-cloudformation-example/...
It’s never taken 30 minutes to pass in a new parameter value for the Docker container.
Also as far as rollbacks just use —disable-rollbacks.
The only time I’ve had CFT get stuck is using custom resources when I didn’t have proper error handling and I didn’t send the failure signal back to CFT.
This is with raw CFT using SAM.
Failed deployments without rollbacks still leave you in a unusable state and manual rollbacks of a failed service deployment can take as long to cleanup as the failed rollback you just disabled especially when dealing with persistent resources. That linked fargate stack is fairly bare bones in comparison to what we run in ECS and we maintain our own AMIs that are built nightly for security updates and ECR resources from docker build pipelines which need to go together in a real AWS environment to have any hope of actually working. A failure in one has cascading effects on others and cleanup is a pain. Passing a new parameter isn't a real exercise and we need a new docker build with every code change. Glad you have a minimalist setup and can get by with what? 10m deployments end to end? Sadly that's not the world I live in...
Why are you running your own AMIs for ECS instead of just using Fargate?
The build pipeline I used in CodeBuild was build the Docker container and a sidecar Nginx container.
The parameter you pass in is the new Docker container you just built.
But how would LocalStack help?
You also don’t have massive CDK apps. The Docker images are going to change much more frequently than your persistent layer. You’re not going to be bringing up and down your VPCs, database clusters etc.
Own AMIs? Simply cost. No other reason, although we're evaluating it again, so we'll see.
We actually have several "massive" CDK projects now, depending on what metric you use for determining size. Our largest CDK app has more than 60 stacks, but with a cellular architecture that's artifially inflating the numbers a bit (n unique stacks against k AWS accounts where k > n but for n > 20, < 100) Maybe the speed at which we change persistent layers (99% additive) will slow down someday, but when you maintain a large number of services (>14) with constantly changing external contracts, it probably won't; it hasn't the last 6 years, it only gets faster.
There's going to be a lot of complaints about open-source restricting access.
It's going to keep happening because it just doesn't make sense for a lot of previous business models that supported and open-source project, something that was seen recently with tailwind.
In one of my projects, one that remains source-available, I had encountered an "open-source justice warrior" that made it their mission to smear the project because of the switch, grasping at straws to do everything they could to paint my intentions as malicious.
It's really too bad, and will only hurt the availability of free alternatives if one cannot provide the source under a "just don't commercially compete with the paid version of the product" license without getting branded as a scamming cash grabber
Source available with various arbitrary restriction is non-free software. What the "open source warriors" take exception to is presenting a project as "open source" or "free" when in reality it is not.
A thing cannot be considered free/open source if there are restrictions on what users can do with it. If a maintainer wishes to put a "don't compete commercially" license then it should be clearly labelled as source available, not open source. To do otherwise is to deceive the open source community, which has a particular and well defined understanding of what "open source" entails.
Are you arguing that copyleft is not open source?
From https://opensource.org/osd:
> 6. No Discrimination Against Fields of Endeavor > > The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
A non-commercial clause is a discrimination against a field of endeavor and thus non-open-source. The license cannot restrict how the user is able to *use* the software and still be open source. There can however be requirements to distribute the source code when distributing the software, ala GPL.
https://opensource.org/sponsors
My main complaint about the project changes we've seen lately is that these companies are happy to take all the code that previous contributors have written for free in good faith, and profit off of it without any sharing. The whole reason I and many people have contributed to some of the projects out there is under the premise that I've been given something great/useful for free so I'm going to give back for free. If you want to create a project that's source-available or whatever you want to call it, from the start, you'll probably even get my support.
Sure, it's totally legal for the company to change how they operate in the future. But it burns all that good faith of previous contributions in favor of profit. And so yeah, I hope the companies that pull this crash and burn in proportion to how much free code they accepted from contributors that they now wish to profit from.
Wrote a blog post advising people not to run this sort of stuff last year: https://developerwithacat.com/blog/032025/test-containers-ba... It's just too much hassle to replicate cloud environments locally, just use unit tests and dev environments.
I bet they will be deleting code from the archived code just like that minio people.
"You either die a hero, or you live long enough to see yourself become the villain"
So is local stack dead? Is this situation the lesser evil? Or is it not dead and we will see a villain rise?
Edit: I see now, they have commercial offerings: https://www.localstack.cloud/pricing
I am not sure if my corp will be willing to pay or tell us to find something else, but I use it everyday, our integration tests depend on local stack.
IMO, the trajectory was set back when they removed the option for monthly payments. Minimum US$450 to play made it a non-starter for my projects (even with commercial ambitions). They changed this just as I started to integrate (~2024, I think) so I kept to the free capabilities. Have been waiting for the other show to drop and here we are.
Edit: looks like they’ve reintroduced monthly billing within the last few months. I guess that’s a sort of win, even if not for the OSS community. But I’d still be reluctant to get into bed with them at this stage.
[dead]
[dead]
[dead]
[dead]
[flagged]
Try proxymock. It's not open source but it is free to use.
That solution can be recreated by a skilled AI boosted senior platform engineer in a few days and parity achieved in a few weeks. Nothing of value was lost.