[Opensim-dev] future rexviewer merger

Sun Dec 7 06:43:21 UTC 2008

Hello,

this sure does shed some light on the path that led to the current 
situation.

Had this work been done in collaboration with the OpenSim team, the 
avatar service might have looked somewhat different and there would 
be no modrex, but rather an SceneObjectMesh one.

I personally would be much happier with that, since I do want the 
meshes for my own application, but don't want the avatar service.

Opensim is not one of those projects that discusses things to death. 
Hypergrid is indeed a good example, it was implemented to the proof 
of concept stage after a brief initial presentation, then picked up 
by the project and integrated. It has led to significant 
improvements in the core, with more to come.

I would hope and I am looking forward to a similar level of 
cooperation with Rex.

Melanie

Toni Alatalo wrote:
> 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
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 