I haven't used it, only read through documentation, but IMO Fluid's problem is not so much lock-in as an embrace of old-school columnar storage and handle-based object manipulation. An experienced Windows developer or game dev might feel entirely at home with the tradeoffs/footguns implied by https://fluidframework.com/docs/build/dds/#picking-the-right... ... but show that to a junior React developer and they're likely to be fundamentally confused, or worse assume that the only code example shown is a valid code example. (People writing documentation: please do not make one of the most prominent code examples in your Getting Started an example of what not to do!). And on the handle front, https://fluidframework.com/docs/build/data-modeling/#using-h... is similarly counterintuitive, to say the least.

Comparatively, I'm much more excited about Automerge https://github.com/automerge/automerge, which promises much friendlier developer ergonomics as simple as:

    doc1 = Automerge.change(doc1, 'Mark card as done', doc => {
      doc.cards[0].done = true
    })

Contributor Martin Kleppman (of Designing Data-Intensive Applications fame) has great overview slides here: https://martin.kleppmann.com/2021/06/04/craft-conf.html . If anything, Automerge suffers from a "there's multiple ways to have a server backend, including P2P and centralized, and no one right way" anti-lockin problem, which is refreshing and also frustrating for people who just want to try something out. This is a solvable problem though!

Thanks for introducing Automerge, and pointing out the pros/cons! Will dig deeper.

I just took a look at the FAQ:

https://fluidframework.com/docs/faq/#can-the-fluid-framework...

I think you have to consider your use case. If you want to build pure online collaboration tool it is fine. But if you want to build something that supports offline collaboration it seems not to be ready yet:

> Clients do have to be connected to the Fluid service. Fluid can tolerate brief network outages and continue operating but eventually the promise of being able to merge local changes weakens. We are investigating ways to improve this using other merging techniques designed to reason over large deltas but no final solution is in place today.

However, what I do like about their approach that they support multiple modern front-end frameworks from React to Vue to Web Components.

Usually projects like this are meant to be used together with Office 365 or for extending Microsoft ecosystem.

Straight from the README, but maybe there are other limitations:

"This project may contain Microsoft trademarks or logos for Microsoft projects, products, or services. Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship."

(Disclosure: Work at Microsoft, but I work in Azure and some open source stuff, not on or directly with Fluid/Office/etc.)

That's just a trademark clause for Microsoft logos and brands. The Fluid Framework itself is MIT licensed [0] and doesn't require exposing any of those logos/brands when you use it, so the framework itself is fairly open for usage.

I think the main thing that would slow down adoption for Fluid is that the only "production" backend is an Azure service, which isn't part of the open source Fluid Framework. Other open source backends[1] aren't recommended for productions. Until there are some open source ones, I'd assume adoption will be limited to folks in the Azure ecosystem.

[0]: https://github.com/microsoft/FluidFramework/blob/main/LICENS...

[1]: https://fluidframework.com/docs/deployment/service-options/

I don't get your point? Doesn't that just mean if you fork the project you can't imply that it is sponsored by Microsoft? I have seen similar clauses in most open-source projects. This seems even more generous in that they don't demand you remove all the trademarks and logos just that you can't use the logo in a way that implies endorsement.

I am not saying whether you should or should not use this product. My point is that before using such products, you need to read really carefully where and how you can use it this product because of the included resources or intended purpose for using this. It is not sufficient to only read the README file and decide based on that.

The key part here is the second sentence "Use of these trademarks or logos must follow Microsoft’s Trademark & Brand Guidelines.". But there can be other such limitations also, just hidden somewhere else.