<div class="gmail_quote">On Tue, Oct 5, 2010 at 4:39 PM, Serge Wroclawski <span dir="ltr"><<a href="mailto:emacsen@gmail.com">emacsen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On Tue, Oct 5, 2010 at 10:50 AM, 80n <<a href="mailto:80n80n@gmail.com">80n80n@gmail.com</a>> wrote:<br>
> It's inevitable that there will be at least one fork of OSM content if the<br>
> license is switched to ODbL + CT.<br>
<br>
</div>That's yet to be seen, unless you're saying that you personally will<br>
make it happen.<br>
<div class="im"><br>
> So the question I'd like to ask is, what things can be done to make such<br>
> projects play nicer and interoperate better when they do happen?<br>
<br>
</div>Unsubscribing from osm-talk will go a long way to making people close<br>
to the project stop being angry with the forkers, if they don't<br>
interrupt our work with constant complaints couched in terms of<br>
"thought experiments" or "theoretical questions".<br>
<div class="im"><br></div></blockquote><div><br>Serge, this is the kind of thing that would achive exactly the opposite of what I am asking for.  Two or more incompatible projects would not help OSM contributors and it would not help users of OSM data.  Who exactly would benefit from what you propose?<br>
<br>You can have thought experiments about there only being one OSMish project if you wish, but it wouldn't be helpful or realistic.  I'm asking for positive and helpful suggestions that deal with the situation that we are going to be in.<br>
<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
>  I'm not<br>
> just interested in technical solutions, but also organisational and<br>
> community based solutions.  What guidelines should duplicate OSMs follow?<br>
<br>
</div>It'll greatly depend on the individuals involved, but some of the<br>
forkers have lost a lot of respect of the OSM community by being<br>
generally disruptive, by making unsubstantiated claims, spreading FUD,<br>
and talking about forking nearly twice a week for several months. At<br>
that point it becomes difficult to work with such a person<br>
collaboratively.  It's possible not all the forkers are like that, but<br>
certainly the loudest forkers on this list have created a situation of<br>
a difficult interpersonal relationship, which will detract from any<br>
attempt at a collabrorative environment.<br></blockquote><div><br>I'm not aware that there's been much talk on this list about forking, and this post is about cooperation anyway.  Perhaps you've been reading some other list.<br>
 </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Once bitten, twice shy, as they say.<br>
<div class="im"><br>
> I'm particularly interested in how it could be made easier for contributors<br>
> to handle the situation.  How will they know which OSM they should<br>
> contribute to?<br>
<br>
</div>There is only one OSM project. Other projects shouldn't be using the OSM name. </blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<font color="#888888"><br>
- Serge<br>
</font></blockquote></div><br>