Comments URL: https://news.ycombinator.com/item?id=47439450

Points: 10

# Comments: 11

You’re right about the "tension" in OSS. That’s exactly why we are pledging to keeping the RustFS core engine permanently open-source. We want to provide the solid, open foundation you mentioned so that teams like yours don't feel forced to build and maintain a storage layer from scratch.

On the sustainability question—you've described the challenge better than most. We're still figuring out the right model, and I don't think anyone has a perfect answer yet. What we do know is that we're building something technically excellent first, and we're committed to doing it in a way that keeps the core open.

We’ve officially updated the CLA to a standard License Grant model. Under these new terms, you retain full ownership of your contributions, and only grant us a non-exclusive license to use them. You can check the updated CLA here: https://github.com/rustfs/rustfs/blob/main/CLA.md.

More importantly, the RustFS team is officially pledging to keep our core repository permanently open-source. We are committed to an open-core engine for the long term, not a "bait and switch."

We know trust matters, especially for a newer project, and we try to earn it through transparency and external validation. we were excited to see RustFS recently added as an optional service in Laravel Sail’s official Docker environment (PR #822). Having our implementation reviewed and accepted by a major ecosystem like Laravel was an encouraging milestone for us.

If the “non-technical reasons” you mentioned are around licensing or governance, I’m happy to discuss our long-term Apache 2.0 commitment and path to a stable GA.

We’re actively reviewing the docs and cleaning up any 404s or navigation issues we can find. For the specific 404 you mentioned, we haven’t been able to reproduce it on our end so far, but we’re continuing to investigate in case it’s environment- or cache-related.

On the licensing side, we want to be clear that we’re fully committed to Apache 2.0 for the long term.

Thanks for the reality check on our documentation. We realize that some of our phrasing sounded more like marketing hype than a technical spec. That wasn’t our intent, and we are currently refining our docs to be more precise and transparent.

A few points to clarify where we’re coming from: 1. The Technical Bet on Rust: Rust wasn’t a buzzword choice for us. We started this project two years ago with the belief that the concurrency and performance demands of modern storage—especially for AI-driven workloads—benefit from a foundation with predictable memory behavior, zero-cost abstractions, and no garbage collector. These properties matter when you care about determinism and tail latency. 2. Language Safety vs. System Design: We’re under no illusion that using a memory-safe language automatically makes a system “100% secure.” Rust gives us strong safety primitives, but the harder problems are still in distributed systems design, failure handling, and correctness under load. That’s where most of our engineering effort is focused. 3. Giving Back to the Ecosystem: We’re committed to the ecosystem we build on. RustFS is a sponsor of the Rust Foundation, and as we move toward a global, Apache 2.0 open-source model, we intend to contribute back in more concrete ways over time.

We know there’s still work to do on the polish side, and we genuinely appreciate the feedback. If you have specific questions about our implementation details or the S3 compatibility layer, I’m happy to dive into the technical details.