The Future of Open Simulator - Accessibility and Business perspective

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The Future of Open Simulator - Accessibility and Business perspective

Nikolaj Lisberg Hansen
Hi OpenSim dev list


I think Douglas question regarding a product roadmap is very relevant, so I
will just comment on it from my point of view, were I want to use
OpenSimulator as a learning platform for K12 students.

I am still new to OpenSimulator, therefore I will try to look at the project
from a accessibility and business perspective and only comment briefly on
the architecture.


My background:

I have worked 20 years as freelance solution architect, senior developer,
product manager for Software Innovation DK and in many R&D units and
recently as enterprise search specialist. I have only developed a few
teacher and student tools with a shared region module for OpenSimulator
http://www.oligo.academy/tools/, so my ideas for architecture are not based
on or limited by practical experience with this platform - think of them as
ideas for a general discussion towards a project road map.  

I think the key driver for everything else, is the accessibility and
business opportunities perspective and therefore also the viewer experience.
There has been some good ideas with the OnLook viewer and PixieViewer, but I
think the scalability and accessibility issues need to be solved in the
backend services.


My short 2 points wish list for OpenSimulator roadmap is:

Priority 1) Make support for new protocols to build fast browser based
viewers and have better scalability

To make OpenSimulator accessible to more people and use cases on any device,
by implementing backend services for browser based viewers. Perhaps using
mean.io stack with MongoDB and also threejs.org (see scene loader example),
to create a cache in MongoDB that makes is possible to build a fast browser
based viewer, by structuring data as the viewer needs it. The browser based
viewer should only have simple build tools and persist to the OpenSim
database. Is the core OpenSimulator code the right place to solve
accessibility and scalability issues or can my suggestion coexist with the
current implementation?

I think it is important to keep compability with existing software stack,
while building new services for new requirements. Linden Labs decision to
move on will make many content creators look towards OpenSim grids and
services like Kitely market.  

Priority 2) Clear and up-to-date documentation

- Make better installation and system management documentation for running
hybergrids, setting up proxy servers to avoid firewall issues and any other
problems users and administrators run into.

- Update plugin and shared region module development examples and
documentation to make it easy for new developers to add features and follow
coding standards. Perhaps make it easy to search for recently updated
information on the opensimulator website.


Why is a project road map so important?

I think it's important to identify long term goals in a project road map:
like what do we need to do to make the best scalable hybergrid platform,
most secure platform for kids, to improve accessibility of this software or
to support content creators and content sharing. Having a roadmap makes sure
the objectives are common knowledge and will help the constant progress.
Having a legal entity like Overte used to be, also makes it possible to get
public funding, which can also help the progress of the project.


Why should accessibility be prioritized?

The goal of a fast browser based viewer protocol or a secure learning
environment, are requirements for schools that have a "Bring your own
device" strategy and need to adhere to children's protection act. It would
also open up the platform for many more users and business cases. When no
viewer installation is required not only school kids would benefit, but also
business cases like online interactive museums, galleries, auctions etc.

I think the support for WebGL is quite good (http://caniuse.com/#feat=webgl
and mature frameworks like ThreeJS have good examples
http://threejs.org/examples/#webgl_loader_scene. Therefore I think the
conditions to succeed are in place, if we can build backend services to
support fast browser based viewers, without the constrains of the existing
protocols.  



PS: Thanks to all people, who have contributed to this great project over
the years, it has a lot of potential - let's make it more accessible to more
people ;-)


Have a nice day

Regards Nikolaj


Freelance solution architect at Olio ApS (http://olio.dk)  


-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: 13. august 2015 19:23
To: [hidden email]
Subject: Opensim-dev Digest, Vol 17, Issue 23

Send Opensim-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Opensim-dev digest..."


Today's Topics:

   1. Re: The Future of Open Simulator(?) (UNCLASSIFIED) (Cinder Roxley)
   2. The Future of Open Simulator(?) (UNCLASSIFIED) (Ovi Chris Rouly)


----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Aug 2015 10:32:09 -0600
From: Cinder Roxley <[hidden email]>
To: [hidden email]
Subject: Re: [Opensim-dev] The Future of Open Simulator(?)
        (UNCLASSIFIED)
Message-ID: <[hidden email]>
Content-Type: text/plain; charset="utf-8"

On August 13, 2015 at 8:14:30 AM, Maxwell, Douglas CIV USARMY ARL (US)
([hidden email]) wrote:
Classification: UNCLASSIFIED?
Caveats: NONE?

Can someone explain to me why the core developers insist on control of the?
code, but refuse to manage the project? I ask again: what are your plans
for?
the future of Open Simulator? It's ok to say you don't have any, let's make?
some!?

I'll throw out some ideas based on the MOSES goals and objectives:?

1) Scale limitations lifted. We need a system that is governed by its?
available hardware and network resources, not bound by software limits.?

2) Let's create clear definitions of "stability".?

3) Clear and up-to-date API documentation.?

4) Clear and up-to-date OS deployment guidance under numerous typical
network?
topologies.?

5) Bug identification & reduction.?

6) Efficient ray tracing. Useful for simulation of sensors as well as?
naturalized bot interactions.?

7) N-body physics. Would be nice to have vehicles that can follow terrain?
and not look like Star Wars land speeders. Would also be nice to have more?
natural avatar movement rather than the rigid animations we use now.?

What are yours? Anyone??

v/r -doug
This can be considered my ?wish list? as I don?t really have a say in what
happens, but I?m willing to put in a fair share of work in seeing that it
can be done if others agree these are desirable targets:

1) Restating what Doug has mentioned, Clear and up-to-date API
documentation. This hinders contributors, myself included, from working on
things and leads to a lot of frustration and disappointed from
well-intentioned folks.

2) A coding standard that defines and formalizes the style of code used
throughout the codebase and is adhered to and enforced and should be pointed
to often and regularly for contributions. Good code is easy to read and
manageable. A formal coding standard is a good step in that direction.

3) OpenSim is a thread monster. There doesn?t seem to be any sort of
approach to how threading is handled. This I think would fall under Doug?s
criteria for #1.

4) I think it?s time to hop off the fence and decide whether to maintain the
Second Life protocol compatibility, (Which, let?s be honest, is pretty
lacking. There?s a lot missing post-2010.) or to break new ground. Linden
Lab has apparently made their decision regarding that. There are viewer
developers out there willing to work with OpenSimulator is doing this. I am
one of them. I just can?t be in IRC all the time, but I want to do this with
you guys and I know there are others out there willing to put in the work to
build clients to connect to new and better worlds with sensible protocols.

Please don?t take any of this as criticism as it is not meant as such. I
appreciate all the work that everyone on this project and who is affiliated
with it does.

--?
Cinder Roxley
Sent with Airmail
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://opensimulator.org/pipermail/opensim-dev/attachments/20150813/5177ff5
d/attachment-0001.html>

------------------------------

Message: 2
Date: Thu, 13 Aug 2015 13:22:57 -0400
From: "Ovi Chris Rouly" <[hidden email]>
To: <[hidden email]>
Subject: [Opensim-dev] The Future of Open Simulator(?) (UNCLASSIFIED)
Message-ID: <000601d0d5ec$b27514c0$175f3e40$@ieee.org>
Content-Type: text/plain; charset="us-ascii"

Doug,

I like all of those ideas.  They would make my life significantly easier and
my research far more plausible!

Chris

George Mason University
Fairfax, VA

>>>>>>>>>>>>

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of
[hidden email]
Sent: Thursday, August 13, 2015 11:38 AM
To: [hidden email]
Subject: Opensim-dev Digest, Vol 17, Issue 22

Send Opensim-dev mailing list submissions to
        [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
or, via email, send a message with subject or body 'help' to
        [hidden email]

You can reach the person managing the list at
        [hidden email]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Opensim-dev digest..."


Today's Topics:

   1. Re: The Future of Open Simulator(?) (UNCLASSIFIED)
      (Maxwell, Douglas CIV USARMY ARL (US))
   2. Re: The Future of Open Simulator(?) (UNCLASSIFIED) (Blake)


----------------------------------------------------------------------

Message: 1
Date: Thu, 13 Aug 2015 14:13:52 +0000
From: "Maxwell, Douglas CIV USARMY ARL (US)"
        <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: [Opensim-dev] The Future of Open Simulator(?)
        (UNCLASSIFIED)
Message-ID:
       
<[hidden email]>
Content-Type: text/plain; charset="utf-8"

Classification: UNCLASSIFIED
Caveats: NONE

Can someone explain to me why the core developers insist on control of the
code, but refuse to manage the project?  I ask again:  what are your plans
for the future of Open Simulator?  It's ok to say you don't have any, let's
make some!

I'll throw out some ideas based on the MOSES goals and objectives:

1)  Scale limitations lifted.  We need a system that is governed by its
available hardware and network resources, not bound by software limits.

2)  Let's create clear definitions of "stability".

3)  Clear and up-to-date API documentation.

4)  Clear and up-to-date OS deployment guidance under numerous typical
network topologies.

5)  Bug identification & reduction.

6)  Efficient ray tracing.  Useful for simulation of sensors as well as
naturalized bot interactions.

7)  N-body physics.  Would be nice to have vehicles that can follow terrain
and not look like Star Wars land speeders.  Would also be nice to have more
natural avatar movement rather than the rigid animations we use now.

What are yours?  Anyone?

v/r -doug

Dr. Douglas Maxwell
Science and Technology Manager
Virtual World Strategic Applications
U.S. Army Research Lab
Simulation & Training Technology Center (STTC)
(c) (407) 242-0209



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Justin
Clark-Casey
Sent: Thursday, August 13, 2015 7:40 AM
To: [hidden email]
Subject: Re: [Opensim-dev] The Future of Open Simulator(?) (UNCLASSIFIED)

I won't comment much over future direction.  However, Overte was never a
governing entity, it was set up only to manage CLAs and maybe some other
things in the future (which never got realized).  Power over development
direction has always been with the developers.

CLAs for open-source projects tend to come from corporations running those
projects that are very worried about getting sued.  The vast majority have
no such structures.  It is very debatable whether anything other than the
open-source license is needed.


And there are many different project structures out there.  Linux, for
example, is controlled by a single individual who, along with a group of
authorized lieutenants, controls everything that goes into the codebase.
That is an evolution since Linus used to be the sole committer (and got
overwhelmed by it).

The direction of evolution is not inevitably to some managing organization.
Or at the very least, the developers much always be in charge of what
happens to the codebase.



On Tue, Aug 11, 2015 at 5:59 PM, Maxwell, Douglas CIV USARMY ARL (US)
<[hidden email]> wrote:


        Classification: UNCLASSIFIED
        Caveats: NONE

        Projects evolve.

        I couldn't begin to estimate the amount of work that has gone into
this
        valuable project.  The potential for technical and economic success
is
        profound and I see a bright future for the Open Simulator.  That
said, I fear
        we are at a crossroads at this time with this project.

        It is unclear at this time what the maintainers of the Open
Simulator code
        have planned for the project.  Is there a roadmap or some sort of
        goals/objectives you are working against?  What development targets
would you
        like to see met in 12, 16, and 24 months from now?

        The MOSES project has needs & requirements that we are stepping up
and
        supporting with internal development, but we aren't the drivers for
the Open
        Simulator project.  We've done our own internal gap analysis and
determined
        where in the OS code there should be investment in stability,
monitoring, and
        scalability improvements.  In short, we are returning our code to
you to
        adhere and abide by applicable derivative source code licensing
terms.

        I believe the removal of the Overte as a formal governing entity is
a mistake
        if you plan to encourage participation from business and government.
The CLA
        was viewed by my organization as a formalized relationship
acknowledging the
        legal responsibility of open source code stewardship and use.

        If this were simply a hobby, then Overte and the CLA would not be
needed.
        However, the Open Simulator is being used by businesses charging
money for
        service, by researchers studying human behavior and technical
behavior, by
        educators, and more.  Like it or not, you have created a product
that needs
        management and attention at a higher level than the ad-hoc method
that is
        currently your standard operating procedures.

        Project management must evolve.

        As projects are started at the grass roots and then emerge as valued
        commodities, the need for different styles of management is
required.  A
        project with two active developers is different than a project with
20 or
200.
        If the management does not evolve, then the project will be limited
and
growth
        is not possible.  I encourage you to think about a new structure
that can
        handle influx of large amounts of donated code in a short time.  The
kinds of
        investments needed to make this a world class simulator requires you
to step
        up and begin project planning.

        This is a community effort.

        If the community values this work and would like to see it grow or
even
        receive maintenance, then the community must voice.  This code does
not
belong
        in the hands of a gov't agency or corporate entity.  This code
belongs in the
        hands of a strong non-profit that can handle grant and contract
funds to pay
a
        staff of maintainers, code reviewers, testers, and functional area
code
        managers.  This could be an Overte spin-off, or even an academic
institution
        of some kind.

        I've given you a glimpse into what the next 9 months of development
for the
        MOSES related Open Simulator issues.  We came in this spring at a
time when
        development seemed to be winding down and things were quiet after
the 0.8.x
        releases.  What will you do when we reach the logical conclusion of
our work?
        What is next for Open Simulator?

        I look forward to your feedback and constructive discourse.

        v/r -doug

        Dr. Douglas Maxwell
        Science and Technology Manager
        Virtual World Strategic Applications
        U.S. Army Research Lab
        Simulation & Training Technology Center (STTC)
        (c) (407) 242-0209



        Classification: UNCLASSIFIED
        Caveats: NONE



        _______________________________________________
        Opensim-dev mailing list
        [hidden email]
        http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev





Classification: UNCLASSIFIED
Caveats: NONE


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5629 bytes
Desc: not available
URL:
<http://opensimulator.org/pipermail/opensim-dev/attachments/20150813/ab16433
e/attachment-0001.bin>

------------------------------

Message: 2
Date: Thu, 13 Aug 2015 11:37:20 -0400
From: Blake <[hidden email]>
To: [hidden email]
Subject: Re: [Opensim-dev] The Future of Open Simulator(?)
        (UNCLASSIFIED)
Message-ID:
        <[hidden email]>
Content-Type: text/plain; charset="utf-8"

I'd love to see a "Convention over Configuration" approach. What I mean is
that OpenSim come configured for best practices.

On Thu, Aug 13, 2015 at 10:13 AM, Maxwell, Douglas CIV USARMY ARL (US) <
[hidden email]> wrote:

> Classification: UNCLASSIFIED
> Caveats: NONE
>
> Can someone explain to me why the core developers insist on control of the
> code, but refuse to manage the project?  I ask again:  what are your plans
> for
> the future of Open Simulator?  It's ok to say you don't have any, let's
> make
> some!
>
> I'll throw out some ideas based on the MOSES goals and objectives:
>
> 1)  Scale limitations lifted.  We need a system that is governed by its
> available hardware and network resources, not bound by software limits.
>
> 2)  Let's create clear definitions of "stability".
>
> 3)  Clear and up-to-date API documentation.
>
> 4)  Clear and up-to-date OS deployment guidance under numerous typical
> network
> topologies.
>
> 5)  Bug identification & reduction.
>
> 6)  Efficient ray tracing.  Useful for simulation of sensors as well as
> naturalized bot interactions.
>
> 7)  N-body physics.  Would be nice to have vehicles that can follow
terrain
> and not look like Star Wars land speeders.  Would also be nice to have
more

> natural avatar movement rather than the rigid animations we use now.
>
> What are yours?  Anyone?
>
> v/r -doug
>
> Dr. Douglas Maxwell
> Science and Technology Manager
> Virtual World Strategic Applications
> U.S. Army Research Lab
> Simulation & Training Technology Center (STTC)
> (c) (407) 242-0209
>
>
>
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Justin
> Clark-Casey
> Sent: Thursday, August 13, 2015 7:40 AM
> To: [hidden email]
> Subject: Re: [Opensim-dev] The Future of Open Simulator(?) (UNCLASSIFIED)
>
> I won't comment much over future direction.  However, Overte was never a
> governing entity, it was set up only to manage CLAs and maybe some other
> things in the future (which never got realized).  Power over development
> direction has always been with the developers.
>
> CLAs for open-source projects tend to come from corporations running those
> projects that are very worried about getting sued.  The vast majority have
> no
> such structures.  It is very debatable whether anything other than the
> open-source license is needed.
>
>
> And there are many different project structures out there.  Linux, for
> example, is controlled by a single individual who, along with a group of
> authorized lieutenants, controls everything that goes into the codebase.
> That
> is an evolution since Linus used to be the sole committer (and got
> overwhelmed
> by it).
>
> The direction of evolution is not inevitably to some managing
organization.

> Or at the very least, the developers much always be in charge of what
> happens
> to the codebase.
>
>
>
> On Tue, Aug 11, 2015 at 5:59 PM, Maxwell, Douglas CIV USARMY ARL (US)
> <[hidden email]> wrote:
>
>
>         Classification: UNCLASSIFIED
>         Caveats: NONE
>
>         Projects evolve.
>
>         I couldn't begin to estimate the amount of work that has gone into
> this
>         valuable project.  The potential for technical and economic
> success is
>         profound and I see a bright future for the Open Simulator.  That
> said, I fear
>         we are at a crossroads at this time with this project.
>
>         It is unclear at this time what the maintainers of the Open
> Simulator code
>         have planned for the project.  Is there a roadmap or some sort of
>         goals/objectives you are working against?  What development
> targets would you
>         like to see met in 12, 16, and 24 months from now?
>
>         The MOSES project has needs & requirements that we are stepping up
> and
>         supporting with internal development, but we aren't the drivers
> for the Open
>         Simulator project.  We've done our own internal gap analysis and
> determined
>         where in the OS code there should be investment in stability,
> monitoring, and
>         scalability improvements.  In short, we are returning our code to
> you to
>         adhere and abide by applicable derivative source code licensing
> terms.
>
>         I believe the removal of the Overte as a formal governing entity
> is a mistake
>         if you plan to encourage participation from business and
> government.  The CLA
>         was viewed by my organization as a formalized relationship
> acknowledging the
>         legal responsibility of open source code stewardship and use.
>
>         If this were simply a hobby, then Overte and the CLA would not be
> needed.
>         However, the Open Simulator is being used by businesses charging
> money for
>         service, by researchers studying human behavior and technical
> behavior, by
>         educators, and more.  Like it or not, you have created a product
> that needs
>         management and attention at a higher level than the ad-hoc method
> that is
>         currently your standard operating procedures.
>
>         Project management must evolve.
>
>         As projects are started at the grass roots and then emerge as
> valued
>         commodities, the need for different styles of management is
> required.  A
>         project with two active developers is different than a project
> with 20 or
> 200.
>         If the management does not evolve, then the project will be
> limited and
> growth
>         is not possible.  I encourage you to think about a new structure
> that can
>         handle influx of large amounts of donated code in a short time.
> The kinds of
>         investments needed to make this a world class simulator requires
> you to step
>         up and begin project planning.
>
>         This is a community effort.
>
>         If the community values this work and would like to see it grow or
> even
>         receive maintenance, then the community must voice.  This code
> does not
> belong
>         in the hands of a gov't agency or corporate entity.  This code
> belongs in the
>         hands of a strong non-profit that can handle grant and contract
> funds to pay
> a
>         staff of maintainers, code reviewers, testers, and functional area
> code
>         managers.  This could be an Overte spin-off, or even an academic
> institution
>         of some kind.
>
>         I've given you a glimpse into what the next 9 months of
> development for the
>         MOSES related Open Simulator issues.  We came in this spring at a
> time when
>         development seemed to be winding down and things were quiet after
> the 0.8.x
>         releases.  What will you do when we reach the logical conclusion
> of our work?
>         What is next for Open Simulator?
>
>         I look forward to your feedback and constructive discourse.
>
>         v/r -doug
>
>         Dr. Douglas Maxwell
>         Science and Technology Manager
>         Virtual World Strategic Applications
>         U.S. Army Research Lab
>         Simulation & Training Technology Center (STTC)
>         (c) (407) 242-0209
>
>
>
>         Classification: UNCLASSIFIED
>         Caveats: NONE
>
>
>
>         _______________________________________________
>         Opensim-dev mailing list
>         [hidden email]
>         http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
>
>
>
> Classification: UNCLASSIFIED
> Caveats: NONE
>
>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://opensimulator.org/pipermail/opensim-dev/attachments/20150813/40c5860
c/attachment.html>

------------------------------

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


End of Opensim-dev Digest, Vol 17, Issue 22
*******************************************



------------------------------

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


End of Opensim-dev Digest, Vol 17, Issue 23
*******************************************

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

The Future of OpenSimulator

Diva Canto
It's really difficult to have a meaningful conversation about the future
of OpenSimulator without understanding what OpenSimulator really is,
from a technical perspective.

Dahlia and Misterblue already mentioned it, but I'll mention it
again.OpenSimulator, as designed by this particular team of developers,
is a framework or an application server, not a complete product. It's
full of hooks so that people can create their own products while having
a good jump start with a bunch of default application behavior. So, off
the box, it looks like SL (plus a few goodies), as that seems to be the
default behavior that most people are/were interested in, to leverage
the existence of the SL viewers; but if you want, it can be made to look
like something completely different.

The best analogy for what OpenSimulator is is this (courtesy of Apple):
https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMapOSX/books/IntegrateYourCodewiththeFrameworks/Art/house_framework.png

At its core, embodied in the dll OpenSim.Region.Framework, it's a 3d
scene manager. That's about it; that's all that's hardcoded. The scene
manager interacts with the rest of the software via a number of
interfaces that are expected to be implemented in some way or another,
and that are all dynamically loaded via an external specification
(plugins). Most notably, there are interfaces for: user clients,
physics, scripting, numerous backend resource services, data storage
providers, and a generic interface for adding any kind of additional
features to the scene manager (aka "Region Modules" given by the mono
addin extension point /OpenSim/RegionModules). There is also an even
lower-level generic interface that allows the injection of additional
features at the server level (given by the mono addin extension point
/OpenSim/Startup).

Just above that core, embodied by several other dynamically loaded dlls,
there is the default application behavior of SL, with almost
feature-full support for the LL protocol
(OpenSim.Region.ClientStack.LindenUDP.dll and many others). This
behavior can be replaced by providing other dlls that implement the same
interfaces. So if you want to support any other client protocol, you
can, by implementing the corresponding interface that the scene manager
expects clients to have.

Using that Apple image of what a framework is, people can have lots of
ideas for how their favorite house will look like. I have mine. But
that's not what OpenSimulator is. OpenSimulator is the framework, plus
the default "Linden house" that can be replaced entirely.

Having explained that, the conversation about the future of
OpenSimulator is a conversation about the future of the framework and
default application behavior that comes with it, not about any
particular alternative "house." There can be separate conversations
about alternative houses, but I doubt they will be of interest to the
exact same team that has built, and is building, the framework.

So what kinds of topics should we talk about when discussing the future
of the framework? Here are some:

1 - The APIs. Some APIs are already pretty solid and flexible, others
are a complete mess. The client API, for example, is a fur ball, because
it is meant to be a generic client API but so far we have had only one
type of client. Unfortunately, it's hard to untangle that fur ball
without having at least another type of client that comes in and
challenges the assumptions made very early on.

2 - Leakage from the Linden application onto the core of the framework.
The picture I painted is very compelling (I hope!) but the reality is
just a little bit different. From early on, there was some leakage from
the design of the Linden house onto the core of the framework. For
example, the data structures we use for modeling 3d scenes are heavily
influenced by how the Linden viewers expect things. It would be nice to
drain the core from that influence. This will be a major undertaking,
and I don't know who among us has time/motivation to do it, but I know
that there have been designs and plans to do it, which unfortunately
didn't pan out.

3 - Documentation of the framework. Community-led open source projects
tend to fare really poorly on this, and OpenSimulator is no exception.
The Wiki is a mess. The code has been the most reliable documentation so
far (for me, at least), followed by asking questions on the IRC. This
raises the bar for what kinds of people can develop addons for
OpenSimulator; people who are comfortable with reading tons of code and
asking questions to complete strangers eventually start to understand
how the framework is architected; people who need to read English get
frustrated and go away. Maybe not a bad entrance criteria for a while,
but if we want more action on the kinds of houses people build, the bar
needs to be lowered by providing documentation. I don't have a solution
for this, because translating from C# to English is a boring job that no
core developer is willing to do [for free], but I sure would love to see
some action!

4 - The ease of finding and sharing alternative implementations of APIs
from 3rd party developers. This one is pretty high up on my priority
list and, in my view, it's the single major technical goal that needs to
be achieved before we can tag 1.0. Without a package distribution system
that connects providers and consumers, frameworks are of very little
use; the only way we can help connect them is to add more things to the
core package, which is alarming -- complexity of software grows
exponentially with the number of modules, not linearly. I have been
experimenting with the mono addins package manager for my own addons;
I'll have more information of how that really fares on the next release,
when some people will have to upgrade my addons using the package
manager command line tool.

5 - The default "house." There is no question in my mind that this needs
some repairs, and I am really happy with how much closer we have been
working with viewer developers. Realistically, this evolution will be
not be a radical departure from what SL is, it will be just a bunch of
small improvements, hopefully leading to viewers that are a lot more
secure and programmable. For radical departures, see above my
description of OpenSimulator and the previous point 4 for how to connect
these more radical "houses" to potential consumers.




_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Loading...