OpenSim and realXtend, 4 months on

Back in February this year, Adam wrote a blog post about a company called realXtend who had, on the quiet, written both a virtual worlds viewer (based on Linden Lab’s codebase) and a virtual worlds server (based on OpenSim).  This combination supported a whole load of new features, including mesh primitives and Python scripting support.

At the time, many of the core OpenSim developers were very interested in this, particularly as realXtend intended to contribute their server changes back into the core OpenSim codebase.  And, as Adam described, they did contribute a complete branch of code (a base OpenSim revision + their changes) to OpenSim.  However, though Adam manfully tried to integrate features from that source into our codebase, ultimately it proved an impossible task.

Why was this?  From my perspective, there were two major problems.  Firstly, OpenSim evolves so fast that by the time the code was given to us, our main trunk line had already significantly changed from the revision against which they based their changes.  This made it extremely difficult to merge their code into the main OpenSim, at least without an extremely good knowledge of the realXtend code (for which you probably need to have been the person who developed it).  Secondly, and this reason is partly related to the first, we are a project that exists largely on volunteer time.  As such, we don’t have the manpower to go and dig out features from the realXtend codebase, and many developers don’t have the inclination.

Naturally, this was communicated to realXtend, at which point it was resolved that the only way for code to come into OpenSim was via patches, at least until enough trust was established to give a contributing developer direct access to the repository.  If the realXtend code was to come into OpenSim, it would have to come in via this route, not as a donated mass.  That way, we could absorb the changes one at a time in a controlled manner, over time building up enough of a relationship with particular realXtend developers to make them part of the core team.  This would mean that the realXtend developers did the bulk of the carrying, though in principle anyone could submit a patch containing code taken from the realXtend codebase.  This doesn’t seem unfair – contributing to an open source codebase requires more than just plopping down a lump of source.  Really, one needs to both work with the core developers to get a patch into the main tree, and then hang around afterwards to fix any problems that might come up.

Unfortunately, to the best of my knowledge, the amount of code OpenSim has received from realXtend so far is precisely zero.  None of the realXtend developers have submitted patches to our Mantis system.  Although their code has been released under BSD license and can be found on Sourceforge, it appears to be based on an old version of OpenSim at around version 0.4 (it’s hard to tell for sure).  This means anybody extracting features from it without a very good knowledge of the code would often face the same uphill task as before.  We largely don’t have the manpower or, as volunteers, the inclination to go and do that.

Now, I want to make it clear that I have absolutely nothing against realXtend and wish them every success.  After all, under our BSD licensing there’s absolutely no obligation for them to contribute code to us.  And we’re also very keen to enable other organizations and individuals to build on top of OpenSim, whether their code is proprietary or open source.  However, it does seem a big shame when realXtend talk about a base track to fix stability issues that none of this basic infrastructure work, at the very least, is finding its way back into OpenSim to benefit the community as a whole.