[Opensim-dev] future rexviewer merger

[Toni Alatalo]

I think Ryan and Adam clarified the main issues, and find that MW draw 
the big picture nicely, so guess that with all the comments there now 
is enough ground that the work can go on and we'll see where. Just 
wanted to share a bit from what I've seen being a bit on&off in&outside 
of the project(s), as there are a couple of points that are perhaps 
good to note as lessons learned. Let it be as two little stories:

a) Failure of taking OS as code and not collaboration
b) Success in developing rapidly as an independent fork (oh that dirty 
word!)

I'm afraid I failed to keep these short enough, so please do skip the 
post freely if not interested in this history! and/or dev process 
thinking, there's nothing technical in this mail.

On Dec 6, 2008, at 12:18 PM, Ryan McDougall wrote:
> On Sat, Dec 6, 2008 at 3:47 AM, Melanie <melanie at t-data.com> wrote:
>> development behind closed doors, without community (OpenSim dev)
>> feedback, then presenting huge patches that are so brittle that they
>> need to be applied without scrutiny or go stale.
> We have had an internal reorganization where our steering group
> re-prioritized open source.

Here we see the first story, a) Failure of taking OS as code and not 
collaboration

The initial plan of the RealXtend project was never targeting anything 
closed, but an open source platform was and is the idea to start with 
(I was not involved at the start). In the early evaluation OpenSim was 
selected as the server component for the whole system. Then the 
development started on top of it.

I think that the mistake that happened here was that the people, having 
little or no experience of open source development from before, took 
the component as a piece of software - something that does what it does 
and you can use to do your own things.

Also there was the idea (perhaps typical Finnish :) to first do 
something worth showing, and only then come forth with it. To not have 
empty talks before that, but actual doing.

So when I got to know Realxtend project in October 2007 (and studied 
OpenSim before going to work there as heard that it was what they use), 
people were busy both doing additions to the server and improving 
things in the core. At the same time, there was the OpenSim community 
doing partly same and sometimes overlapping but differing things (in 
November 2007 things like network queue / packet code optimizations, 
some guys did a packet priorization system for Rex, i don't know what 
happened with that eventually. Physics improvements were on the list 
too, but as I saw that Dan (and later was it Ter?) was doing them too, 
it was not touched on the Rex side then). And there was no 
communication from Rex to outside, as the plan was to first implement 
the features to be able to show them.

The daily practice of the server development showed the mistake in this 
idea in two ways: 1. there were people working on same things at the 
same time (e.g. network code both within Rex and someone else out 
there) without knowing about each other. 2. Rex version of the codebase 
was not getting the improvements from OpenSim automatically, so there 
was the tedious job of merging by hand periodically (it started taking 
considerable time).

Even just these wasted work hours made it easy for me to argue strongly 
for the management that the development model was flawed, and instead 
coming to open, practicing tight communication and sending patches 
without delay would be needed. This even lead to a decision that devs 
were allowed and encouraged to send patches, but I guess as there was 
no experience with that it didn't just start happening by itself (I now 
see that made a mistake there myself too, should have continued with 
the push and try establish mechanisms too for getting it going, and not 
just the permission to do so .. then again already in December I got 
pretty busy with our game dev project).

Anyhow I think the basic mistake here was taking OpenSim as piece of 
code, and not as a collaboration. It is not just about the code there 
is, but also about the people and companies developing it, forming a 
shared understanding when shaping new things etc. Not a sitting duck, 
but a moving target where it makes no sense to diverge for 6 months to 
do isolated dev and then present results, 'cause others elsewhere are 
going to be doing the same things anyway. Exactly because many people 
and companies need similar things from software open source makes 
sense. This is kind of implicit in open source practices and the normal 
natural thing for people used to it, but not self-evident to outside. I 
hear others have made the same mistake, reportedly Nokia did it with 
Gnome first (forking for their Linux tablet, getting similar 
difficulties, then starting to collaborate) .. I don't know how the 
Apple - KHTML => Webkit thing went, perhaps better (it did start with a 
pretty large patch that had been worked on for .. months?).

ok but then the other side, as it has a lesson too:

b) Success in developing rapidly as an independent fork (oh that dirty 
word!)

I think it's fair to say that Rex has succeeded in bringing interesting 
new stuff to the table, some of it pretty efficiently too. Further I'd 
say that it is also thanks to it being an independent fork, where 
people have been free to innovate. The management has set some goals 
(like the global avatar system), and has been free to do that based on 
their own vision, and the developers have been pretty free to implement 
things straightforwardly to get them working.

Please don't get me wrong, but I don't think the same pace of 
development would have been possible within actual OpenSim development. 
Even the time needed to explain ideas in emails etc. would have been a 
lot. But even more work would have been in coming to a shared 
understanding of how to e.g. refactor the core so that some Rex changes 
that break LL compatibility could be implemented as modules etc - the 
work that has happened now, one full year later.

So it now seems to me that forking, or perhaps branching, is also a 
good way (perhaps especially for a team in one place where 
communication is easier) to *rapidly prototype* new features. Then 
getting them to actual OpenSim is more like standardizing them, so that 
we have a common solid base there for the future.

I think we have recently seen a good example of that with the Hypergrid 
work - it was independent work, based on an own vision, first made as a 
fork. The idea was not first talked and debated to death, but AFAIK 
pretty much implemented and then presented, and liked by others. Then 
the work started targeting integrating to the standard core.

In a way Rex has done the same, but with many things at the same time 
and with too long time spans of not communicating to stay in synch. 
Anyhow the result is similar (has been since February..): a working 
implementation of interesting ideas so we can discuss the designs. I 
think even overlapping work and conflicting designs can be a good 
thing, 'cause then we get alternative views to base on when trying to 
come up with a good design. So let's not be too afraid of forks, but 
embrace them!(?)

For the actual technical / design issues, I think it's a good idea to 
do like Ryan proposed and discuss those in separate threads. I'll start 
one with the next post.. (it'll be short i promise!)

~Toni