Customers are the ones that continue to pay. If they continue to pay they will likely receive maintenance from the devs. If they don't, they are no longer or never have been customers.
It would be interesting to see if there could be a sustainable OSS model where customers are required to pay for the product, and that was the only way to get support for it as well. Even if the source was always provided (and even if it were GPL), any bug reports/support requests etc. would be limited to paying customers. I realize there is already a similar model where the product/source itself is always free and t…
Well, I think this is what SchedMD do with Slurm? GPL code. You can sign up to the bug tracker & open an issue, but if you don't have a support contract they close the issue. And only those customers get advanced notice of CVEs etc. I'd expect nearly everyone who uses it in production has a support contract.
Isn't this the normal sales anyhow for many products? One attracts a customer with unreasonable promises and features, makes him sign a deal to integrate, then issues appear once in production that make you realize you will need to invest more. When you start something (startup, FOSS project, damn even marriage) you might start with the best intentions and then you can learn/change/loose interest. I find it unreasona…
> I find it unreasonable to "demand" clarity "at the start" because there is no such thing. Obviously you cannot "demand" stuff but you can do your due dilligence as the person who chooses a technical solution. Some projects have more clarity than others, for example the Linux foundation or CNCF are basically companies sharing costs for stuff they all benefit from like Linux or Prometheus monitoring and it is highly…
First off, I don't think there is anything wrong with MinIO closing down its open source. There are simply too many people globally who use open source without being willing to pay for it. I started testing various alternatives a few months ago, and I still believe RustFS will emerge as the winner after MinIO's exit. I evaluated Garage, SeaweedFS, Ceph, and RustFS. Here are my conclusions: 1. RustFS and SeaweedFS are…
> RustFS and SeaweedFS are the fastest in the object storage field.
I'm not sure if SeaweedFS is comparable. It's based on Facebook's Haystack design, which is used to address a very specific use case: minimizing the IOs, in particular the metadata lookup, for accessing individual objects. This leads to many trade-offs. For instance, its main unit of operations is on volumes. Data is appended to a volume. Erasure coding is done per volume. Updates are done at volume level, and etc.
On the other hand, a general object store goes beyond needle-in-a-haystack type of operations. In particular, people use an object store as the backend for analytics, which requires high-throughput scans.
Ceph is a non-starter for me because you cannot have an existing filesystem on the disk. Previously I used GlusterFS on top of ZFS and made heavy use of gluster's async geo-replication feature to keep two storage arrays in sync that were far away over a slow link. This was done after getting fed up with rsync being so slow and always thrashing the disks having to scan many TBs every day. While there is a geo-replicat…
Ceph is a non-starter because you need a team of people managing it constantly
Yeah sure. I manage a ceph cluster (4PB) and have a few other responsibilities at the same time.
I can tell you that ceph is something I don't need to touch every month. Other things I have to baby more regularly
What is especially annoying is the aistor/minio business model, either get the „free“ version or pay about 100k… How about accepting some small dollars and keeping the core concept?
However this seems to be the business type of enshitification. Instead of slapping everything with ads, you either pay ridiculous dollars or move on.
Maintainer of Milvus here. A few thoughts from someone who lives this every day: 1. The free user problem is real, and AI makes it worse. We serve a massive community of free Milvus users — and we're grateful for them, they make the project what it is. But we also feel the tension MinIO is describing. You invest serious engineering effort into stability and bug fixes, and most users will never become paying customers…
GPL for open source and commercial license for the enterprise lawyers. Unfortunately, a majority seems to hate GPL these days even though it prevents most of the worst corporate behaviors.
Minio was AGPL, which was a perfectly fine tradeoff IMO. But apparently that wasn't good enough.
GPL for open source and commercial license for the enterprise lawyers. Unfortunately, a majority seems to hate GPL these days even though it prevents most of the worst corporate behaviors.
Minio was AGPL, which was a perfectly fine tradeoff IMO. But apparently that wasn't good enough.
AGPL doesn't help when you want to kill your free offering to move people onto the paid tier. But quite frankly, that isn't a problem GPL is meant to solve.
> Elastic, Redis, Terraform, now MinIO. Redis is the odd one out here[1]: Garantia Data, later known as Redis Labs, now known as Redis, did not create Redis, nor did it maintain Redis for most of its rise to popularity (2009–2015) nor did it employ Redis’s creator and then-maintainer 'antirez at that time. (He objected; they hired him; some years later he left; then he returned. He is apparently OK with how things en…
Things are a bit more complicated. Actually Redis the company (Redis Labs, and previously Garantia Data) offered since the start to hire me, but I was at VMWare, later at Pivotal, and just didn't care, wanted to stay actually "super partes" because of idealism. But actually Pivotal and Redis Labs shared the same VC, It made a lot more sense to move to Redis Labs, and work there under the same level of independence, so this happened. However, once I moved to Redis Labs a lot of good things happened, and made Redis maturing much faster: we had a core team all working at the core, I was no longer alone when there were serious bugs, improvements to make, and so forth. During those years many good things happened, including Streams, ACLs, memory reduction stuff, modules, and in general things that made Redis more solid. In order to be maintained, an open source software needs money, at scale, so we tried hard in the past to avoid going away from BSD. But eventually in the new hyperscalers situation it was impossible to avoid it, I guess. I was no longer with the company, I believe the bad call was going SSPL, it was a license very similar to AGPL but not accepted by the community. Now we are back to AGPL, and I believe that in the current situation, this is a good call. Nobody ever stopped to: 1. Provide the source on Github and continue the development. 2. Release it under a source available license (not OSI approved but practically very similar to AGPL). 3. Find a different way to do it... and indeed Redis returned AGPL after a few months I was back because maybe I helped a bit, but inside the company since the start there was a big slice that didn't accept the change. So Redis is still open source software and maintained. I can't see a parallel here.
> For an open-source project to achieve long-term reliability and growth, it must be backed by a sustainable commercial engine You mean like Linux, Python, PostgreSQL, Apache HTTP Server, Node.js, MariaDB, GNU Bash, GNU Coreutils, SQLite, VLC, LibreOffice, OpenSSH?
Actually, Linux reinforces my point. It isn't powered solely by volunteers; it thrives because the world's largest corporations (Intel, Google, Red Hat, etc.) foot the bill. The Linux Foundation is massively funded by corporate members, and most kernel contributors are paid engineers. Without that commercial engine, Linux would not have the dominance it does today. Even OpenAI had to pivot away from its original non-…
> Even OpenAI had to pivot away from its original non-profit, open principles to survive and scale.
Uh, no, OpenAI didn't pivot from being open in order to survive.
They survived for 7 years before ChatGPT was released. When it was, they pivoted the _instant_ it became obvious that AI was about to be a trillion-dollar industry and they weren't going to miss the boat of commercialization. Yachts don't buy themselves, you know!
There's nothing wrong at all with charging for your product. What I do take issue with, however, is convincing everyone that your product is FOSS, waiting until people undertake a lot of work to integrate your product into their infrastructure, and then doing a bait-and-switch. Just be honest since the start that your product will eventually abandon its FOSS licence. Then people can make an informed decision. Or, if…
It's part of the due diligence process for users to decide if they can trust a project. I use a few simple heuristics: - Evaluate who contributes regularly to a project. The more diverse this group is, the better. If it's a handful of individuals from 1 company, see other points. This doesn't have to be a show stopper. If it's a bit niche and only a handful of people contribute, you might want to think about what hap…
The other heuristic I would add is one that works for commercial/closed source too: evaluate the project exactly as it is now. Do you still want to use it even if 0% of the roadmap ever materializes?
With open source, the good news is that that the version you currently have will always be available to you in perpetuity - including all the bugs, missing features, and security flaws. If you're ok with that, then the community around the thing doesn't even matter.