What would "help" is agreeing to break compatibility, which would definitely require a fork (or a "version 2.0", which is what the community keeps, in moments of darkest despair, suggesting). But an incompatible Subversion is hardly a Subversion at all (regardless of its name, number, or origin).

And I think I once even saw a point made without astro-turffing!

You know, even here in /., it's not absolutely *mandatory* that your arguments be wholly ad-hominem.

Dude! I think you've solved it!

Instantiating a fully open core, on which to deliver proprietary add-ons, is a harder model: it requires the implementation domain to actually have such a division, and it requires a lot of investment in that core ... probably more than any one company is prepared to spend, merely to release it utterly to anyone's use. There are a few cases where this has worked, notably of course the Apache projects (and most notably, httpd): many companies collaborated to create the core, so they could build value on top (mostly in the form of web sites/applications, rather than httpd add-ons per se, but the economics are the same). But such opportunities are rare.

Careful requirements are certainly important, but so also is competence. No requirements document was ever complete. There will always be decisions to be made beyond the document, and they have to be made with proper respect for the fundamental objectives. The BP is correct: "To have a company intimately involved with *security* not apparently able to manage their own security in a manner that protects the country and their customers is a joke." If not something worse.