What I look for in an Open Standard is that it is useful, easy to understand and use. JSON is the perfect example. But it is much less complex than FFF. Let’s take one element of FFF: the VCS repository itself.
The top down approach would be to define a VCS in FFF as any kind of known VCS and provide a list with normative names so there is no ambiguity: RCS, CVS, SVN, GIT, HG etc. And the reference implementation would only cover some of them. The others would be left to the interpretation of the reader which is another way to say: we did not think about it, deal with it. Exactly what I do not want in an Open Format.
The bottom up approach would be to define a VCS in FFF as whatever is supported by the reference implementation. Which is critically important, for instance to represent the notion of pull request. With the reference implementation, the specifications and the sample data, it is possible to understand, down to the last detail how a pull request described in FFF relates to the content of the VCS. Of course it is possible to add RCS as well and the reference implementation would just verify that the notion of pull request is deactivated / incompatible with this particular VCS.
So FFF is, by nature, an ever growing set of elements: rather than being extensible, I’m under the impression that it is a consistent set of elements (VCS is one of them, discussions/mailing lists another, issues yet another, etc.) that evolve independently. Its main purpose is to provide versioning, consistency, backward compatibility, reference implementation that bind these elements into a consistent set.
Does that make sense to you?