"But centralized version control does need to become more open. The difference between someone with commit access and some random contributor should be reduced"
True to a very large extent and it focusses on a very important issue. Subversion has a very specific problem when used with free/open source projects. It pretends that patch management is none of it's business, since all it promises to be is a better CVS. But remember that CVS itself is probably two decades old and should not be setting the bar for any version control software beyond a certain extent. Now we know after a decade+ of distributed software development in which not everyone has commit privilieges, that there are problems with the way patches are handled. But it probably best not to depende on the SVN project itself to do this. As you note in another excellent point:- "There's great potential in version control -- but it's all in usability and tools, security and scaling, not the mathematical appeal of patch management algorithms.". Tortoise SVN and SVK are the only two SVN based projects that have had any real impact. I am not sure though about that bit about "patch management algorithms". It's a prominent shortcoming/defect in SVN that it does have a real handle on objects through object IDs - there is no way to clearly answer the question "Is file A on branchA the same as the file A on trunk"; also lacking is true renames. Merge Tracking will not really be possible unless these are sorted out.