It's inevitable that there will be at least one fork of OSM content if the license is switched to ODbL + CT.  <br><br>There are already other projects using the OSM software stack (CommonMap, USGS etc) but none that I know of that are yet using OSM's content.  This will surely change if the license is switched.<br>
<br>So the question I'd like to ask is, what things can be done to make such projects play nicer and interoperate better when they do happen?  I'm not just interested in technical solutions, but also organisational and community based solutions.  What guidelines should duplicate OSMs follow?<br>
<br>I'm particularly interested in how it could be made easier for contributors to handle the situation.  How will they know which OSM they should contribute to?  Which data source is compatible with which OSM?  Can they easily contribute to more than one instance?<br>
<br>I'm also interested in what can be done to make it easier to combine content from multiple OSM instances.  Suppose one OSM instance has better content for Australia, while another has better content for India.  Some users may be able, licensewise, to combine the best of these.  What things would make it easier and what would make it harder for that to be done?<br>
<br>Are there any easy and simple steps that can be taken that could make the existence of multiple OSMs a whole lot less painful?<br><br><br>