The problem is that “The OCaml Platform” is not a platform. It’s a product: a selection of tools. OCaml (by which I mean whoever controls e.g. ocaml.org) should not be in the business of picking winners in the tooling marketplace. Any more than they should be picking winners from among OPAM packages, which I don’t think is controversial. For example I assume nobody thinks it would be a good idea to declare a particular package is the One True JSON package for OCAML.
I think Clojure is a good point of comparison. For a long time Leinengen was the most popular build tool, but it was not the only option. Clojure faced all the problems OCaml faces with respect to getting started. Had somebody proposed that Leiningen be officially declared as “The Frontend of The Clojure Platform”, Rich Hickey would have (I assume) immediately rejected that, and would have been right to do so. Eventually Clojure came up with its own (superb) build tooling. That probably won’t (and should not) happen with OCaml, but the point remains: picking an early winner would have squashed innovation in the space.
Having said that, let me be clear: I am not arguing that work on the Platform should stop. I’m not even arguing that it should not use Dune. On the contrary, I think its a good project. But it is a product, not a platform, and it should not called “The OCaml Platform”. Rather, like any product, it should be given a distinctive name (trademarked by the OCaml Foundation). For example, “The X Toolsuite” where X could be “Dromedary” (or “ODromedary”), or Bactrian, or Caravansary - no shortage of camel-related terms. It should be promoted as one among many possible such toolsuites (or “dev environments”). It could even be officially supported (or even "endorsed*) by the Powers that Be, but only so long as it is made clear that such endorsement does not mean “recommended to the exclusion of alternatives”. It would just mean “you can trust this stuff to work pretty well if you decide to use it.”
The primary reason I oppose blessing Dune (plus OPAM) as the official build system for OCaml is because as build systems go it is just not very good. It’s very good indeed at somethings, but also very bad at some essential things (like extensibility). Furthermore, I expect that over the next year or so Bazel will become a practical alternative for any OCaml project. The rules already work (and have built largish projects like Mina and Tezos) and tooling to automatically convert from Dune to Bazel is pretty close to done. Bazel can build the compilers (I just built 5.1.0-rc3). The remaining hard problem is how to publish Bazel-based packages to OPAM. On the other hand, I’ve added support for the Bazel module system, which means that for a fully Bazelized project OPAM is not needed. In any case, soon it will no longer be true that Dune is the best choice.
Furtherfurthermore, the Dune-to-Bazel conversion tooling uses a build-system agnostic intermediate language, which means that writing a tool to emit, say, ninja files should be feasible. Which opens up yet more tooling possibilities.
I’ll post details over coming weeks.
Regarding “platform”: to me a platform is a collection of public, standardized data schemas, APIs, and protocols. “The OCaml Platform” is not that. The major problem facing OCaml is lack of such (tooling) schemas, APIs and protocols (they’re not entirely lacking, just inadequate.) It is not the trouble users have getting started - those are just symptoms. Its the trouble toolmakers have building the tools that would make life easier for beginners. Dune is about as unfriendly to toolmakers as it gets. The build protocol for the compilers is poorly documented. Many tools in the ecosystem fail to follow good tooling practice - for example, hardcoding file paths for inputs and outputs, inadequate command-line options, etc. Lots of small things that add up to a lot of headachery. Addressing those issues, especially making the build protocol clear, might well have a bigger impact than blessing a set of current tools as the One True Platform.