[Opensim-dev] Direction of Opensim and its relationship with viewers
Sean McNamara
smcnam at gmail.com
Sun Nov 10 02:36:12 UTC 2013
Hi:
I do not at present see any immediate threat to the model of having
OpenSimulator serve primarily as a SL workalike, and the vast majority of
TPVs supporting OpenSimulator.
We have a vibrant community of numerous TPVs that support OpenSim, and
their developers are generally mutually cooperative, much more than the
upstream Lindens, in terms of sharing patches and working to get features
from one viewer to ported another, whenever it makes sense to do so.
I think the status quo is going just fine, and it's very nice that
OpenSimulator is designed in such a way that its default, out-of-box
behavior is to effectively be an open source SL Server, while it's not all
that hard (from an engineering perspective) to use the OpenSim codebase as
a starting point for working on something completely unrelated to SL.
The only threat I see potentially on the horizon would be Linden Lab
deciding to turn off the code faucet for the mainline viewer. The mainline
client code has more or less kept all the TPVs in mutual compatibility
because they all, eventually, pull from Linden's tree; similarly, OpenSim
makes decisions on which protocols and features to implement based on what
LL does. It would be an exaggeration to say that we're all in lock-step
with Linden, since that is far from true, but I feel there is an overall
cohesion of the community around Linden's source tree because it's hard to
say no to new features when all you have to do is work their patchset into
your tree (which can be excruciating at times, but still a lot easier than
writing it from scratch).
If Linden Lab were to turn off their open source repos and take their tree
of the mainline client back into closed-source land, they would not have to
obtain permission from any contributors to the mainline codebase, because
everyone who's contributed has (as far as I know) signed the Contribution
Agreement, which can be read here:
http://wiki.secondlife.com/wiki/Linden_Lab_Official:Contribution_Agreement
The Contribution Agreement is a copyright assignment. If all non-LL
contributors have signed the CA, then all code in the Linden master tree is
copyright Linden Lab. They can therefore decide to change the license on
the code at any time, to a BSD license, proprietary license, or anything
else of their choosing. Once they've moved away from a copyleft license,
they can then legally release closed-source binaries and turn off the
publicly accessible repositories.
This would result in the TPVs becoming out of sync with new features LL
introduces, which would, over time, increase the amount of work required by
TPVs to maintain compatibility with both OpenSimulator and Second Life
within the same viewer. LL could theoretically decide to break the protocol
to such an extent that the viewers would have to reverse engineer the
protocol very carefully to support Second Life at all, eventually leading
to the mainline viewer being the only viewer SL would support.
Furthermore, without the unifying force of the Linden codebase, the TPVs
themselves might fragment in terms of their feature support, and we'd see
less feature parity between them. Unless of course, someone stepped forward
and volunteered to be a sort of "replacement for Linden's upstream" as a
vanilla, non-political repository to share bugfixes and features for all
TPVs to be based off of. If such a thing existed, we would once again be
secure in having a harmonious OpenSim and TPV relationship, even without
Linden Lab's continuous updates. Of course, all fixes and features after
that point would have to be done by the community and not LL, but that's
not such a bother with as big of a community as we have...
Oh, and just in case you doubt LL would do that, there are plenty of
examples in recent years. OpenSolaris was killed and closed-source into
Solaris, and that's an entire operating system by a major vendor. But I
think that our community could overcome such an event, even if it would be
a big blow and potentially cause a lot of chaos at first.
Overall, considering all the possible scenarios, I think the
OpenSim-as-an-SL-alternative community (of both users and developers) is
strong, and will be resilient to external changes and pressures for a long
time to come. The fact is, people care a lot about this specific use case
of OpenSim, and TPVs care a lot about the use case of running their TPVs
with OpenSim. We're open 24/7, 365 days a year... Happy Hacking :)
-Sean
On Sat, Nov 9, 2013 at 3:38 PM, Taoki <Mircea_the_Kitsune at hotmail.com>wrote:
> Although I've used Second Life and Opensim for more than 6 years, I'm
> still uncertain where the "open virtual worlds" system based on them is
> going, and the direction Opensim might take in relation to SL. Especially
> since during the last years Linden made a lot of major changes, but Opensim
> doesn't seem to have gotten more popular or attractive to main grid users.
> This uncertainty kept me from spending as much time in SL and the free
> grids, and spending more time seeking answers and looking for alternatives.
> Although such matters were probably discussed a lot in the past, I'd like
> to get into the things I'm looking to clarify, and also mention what I
> believe in case it might be helpful for future development plans.
>
> SL and Opensim are two different projects developed by different teams,
> each going in its own direction more or less. The Second Life viewer is a
> client for Linden's virtual worlds system (capable of connecting to other
> grids if modified) while Opensim is a virtual worlds server not officially
> intended for a specific client. Yet for the purpose to be achieved, they
> both need each other. SL doesn't have another open-source server, Opensim
> doesn't have another reliable client. Realistically speaking, neither of
> the two matters will likely change: Linden might never open-source their SL
> server, and Opensim won't have an own client written from scratch that has
> all of SL's features and quality.
>
> Linden proved they don't care about Opensim, so things will likely not
> change on the viewer's end. What jumps to my attention is that apparently,
> Opensim is still waiting for something that will likely never come.
> Although custom SL viewers are the only usable clients, Opensim still goes
> for a "general purpose virtual worlds server" and avoids being labeled as
> "a server for Second Life", while hesitating to get its own official viewer
> based on SL. While at some point I believed an independent structure could
> work, I now think there are too many technical implications for such to be
> possible.
>
> Unlike simpler systems (like http, where Apache doesn't care if it's being
> accessed by Firefox or Chrome) something of this complexity needs a precise
> client - server design. If the server lacks features in the client, the
> client will have dead parts. If the server has more features than the
> client, it will eventually get slow bloated and confusing. Both the server
> and all viewers accessing it need to revolve around a fixed design and set
> of features, otherwise you'd have things only some avatars can see or use
> in your sim. A different virtual world for example might not even use our
> concept of primitives, could have voxel terrain instead of heightmaps, and
> its own scripting language (like Lua) over LSL. Opensim wouldn't be able to
> take it under its wing while staying compatible with SL, since the
> technologies couldn't intersect or be compatible across viewers. It's like
> intending a dedicated server for first person shooters to run Unreal
> Tournament, Quake, DayZ and others at once.
>
> More technically, this is why I believe a non-SL viewer will never exist:
> First of all, everything would have to look almost the same, since we
> wouldn't want those using the SL viewer to see something different than us.
> Terrain, primitive shapes, texture effects (transparency, shiny, bump,
> glow), avatar meshes (customized body, clothing, skins, attachments), the
> sky (day / night cycle and windlight settings), LSL functions with
> client-side effects (llSetText, llTargetOmega, etc) would all need to
> match. Once the world looks fine, you'd need to implement tons of other
> unique and complex features... such as media and web pages on prims, main
> map and minimap, the text and voice chat systems, and so much more. The
> details and eye candy would need attention too, such as a GUI and shaders
> (for HDR, shadows, depth of field) that can rival SL's. Even if someone had
> the time and energy to do all this as a FOSS application, they'd end up
> with a reverse-engineered version of the SL viewer that has little
> differences... meaning they wasted months doing something that's already
> there. In the end, any client for Opensim could only be Second Life, even
> if rewritten from zero and under a different name.
>
> Considering this, I'm curious why it's better for Opensim to aim at being
> a general platform, rather than simply a server for the SL technology. And
> why the dev team doesn't create an official Opensim Viewer based on the
> latest version of SL, while of course allowing custom viewers like
> Firestorm to work too. Is OS still intended to work with other designs, and
> why / how? Does it risk distancing from SL viewers at some point, in hopes
> of a viewer written from scratch? Or does it intend to support a collection
> of different virtual world programs somehow? Also, what would happen if
> third party viewer developers ever got bored of supporting Opensim?
>
> This is not to say what must or mustn't be done, since I'm far from having
> the knowledge and position to decide such things. But sticking to just SL
> and being closer the development of its viewers is something I thought
> would be a good initiative. I still feel that a change is needed, and that
> Opensim isn't reaching its full potential for some reason... which made me
> wonder if among other problems, some might have similar concerns about
> Opensim's colder relationship with viewers, and the lack of something
> specific officially intended to work with it.
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20131109/62b94430/attachment-0001.html>
More information about the Opensim-dev
mailing list