METROPOLIS METAVERSUM

I JUST, just found this thread and it's a lot to digest!

I'm not a programmer, I'm decent at testing and filling out bug reports but I'm one of those people who are very conservative in how they use software so I'm not sure I would be much help.

One thing I want to add, however is this:
You have to be appealing to open source coders and be attractive to them. In my mind, that means using a programming language that most people know. My suggestion would be C or C++. I believe that one of the many hurdles that puts people off from contributing to opensimulator is the fact that it's written in an obscure fad language that no one wants to learn.

You want to do what you can to foster a culture of contribution; make it easy for people to contribute code, make it easy for people to write code (by choosing a sane language).

Hi Han,

I agree with you that the need to be appealing is very important. Attract volunteers need an open atmosphere in the project, one must find the necessary information without asking a lot of people in secret meetings, and be able to publish the own ideas on an attractive, modern platform. Maybe a wiki, maybe something I don't know, but something open for shared work on the same documents.

I disagree with C/C++ outside of a few really hardcore rendering subroutines. The reason is that it allows pointers directly to memory. Pointer errors often result in memory leaks or runtime crashes really hard to find, and that was the reason to use "managed code" in modern programming languages. But I think the programming language is something to be discussed much later, the first passage I think actually is much more significant.

EDIT: With reference to "rendering subroutines" I must say that I don't believe we find enough extremely talented designers that we could write an own rendering engine. I see this project mainly as an interface project: re-using existing open source code for the core components and fit them together with interfaces. Maybe Mumble for voice, some chat tool for IM and stuff, Bullet as physics engine, (something more modern than) Ogre for rendering and so on.

Ciao,
Mareta

I agree that choice of programming language is very secondary if we are to start from scratch. Actually, if we do it the right way, starting with what is needed and desired in terms of functionality and performance, and define this properly in terms of protocols, there is nothing stopping us from more than one group working on this and in more than one programming language. Look at the web as an example. Not all servers and browsers are written in the same language and by the same group there, but they still play together thanks to the common HTTP (and a few other protocols).

Much of the reason for the jam OpenSimulator is in now is that it has always been a "tech" project, run by techs looking more to the technical possibilities than the needs and desires from the community using the software. This has also caused a selection of programmers working with it who are comfortable with those standards, including the lack of contacts with the community.

I have been following OpenSimulator development since 2008, including the politics around it, and seen many developers with a community focus being mobbed out by the core developers, because they were "difficult" and did not fit in. Even some former core developers left the project for that reason. That is why I don't see any viable future for the OpenSimulator project in its present form, regardless of if single new "stars", like Ubit Umarov, pop up, and how many new features and "improvements" they manage to overload the platform with.

So, one critical question is, who should decide what the aims of this project is? Some techs looking for cool new features? Some vocal users with a very strong focus on e.g. vehicle physics or mesh? The present user base, which in all honesty is small and much more tech oriented than the average of SL users, and even further from the much more popular and socially oriented worlds like IMVU? Or people looking at the future potential of what is required to make OpenSimulator really big, useful and popular across many user groups?

Another critical question Han and Mareta pointed out is how to make the project attractive, and I'd add to who? Personally, I believe it's a matter of much more than just attracting developers, and I think Mareta is right in that an open atmosphere is important to attract the kind of persons at least I would feel comfortable working with. And then not "open" as in just pushing out a lot of information, but also welcoming feedback and discussions, even if those would not be along the lines of what present management considers "right".

I would like to chime in. The vision of the current OpenSimulator project, when it was fairly new and by the original programmers, was to become "the" new 3D internet. I will readily admit that this is second hand knowledge. Greybeard knew the original creators of Opensim, has interacted with them and told me.
I think this aim has become lost during the course of the project. There is no one goal or even a set of goals that people work for. I cannot even say what the aim of the current project is - or if it even has any. And I think that is one of the biggest problem the current team faces. I have stopped programming long ago and lost touch, so I am also one what could not help with the actual code.

The second problem as I see it is leadership - like Magnuz says. I don't think it is neccarily a problem when leadership changes, but it IS a problem when it doesn't exist. And I am not saying that leadership is neccessarily one person only. But someone has to decide where the project is aiming and what steps are taken to get there. If it is a group of people, measures need to be in place to ensure timely decision making. Those premises will have to be followed if a project ever wants to reach its goal(s).
I know this is highly theoretical, but from what I have seen of the current project is that someone had a good idea and started on that idea, someone else got interested and it went pretty organically from there, then got so big that one or even two people couln't handle its steering anymore. The way I see it is: it became an "amorphic beast" that went this way and that, depending on who did the coding. Project Management? Virtually non-existing. My point? Some form of project management is needed if you want an actual project, not an excercise in coding.

I have had wonderful talks with core developers and I truly thank them for the time and effort they devoted to get OpenSim where it is today. I think despite, not because of, the way the project was / is handled. Best example for this is the documentation. That's right: There isn't really any. And that is the mistake. That is first and foremost the element why new programmers to help out - even if they are willing - are so hard to find.

I also agree with Magnuz. More than "just" programmers are needed to get this project rolling again. Yes, no code, no project, but it takes all kinds of people to make it successful. We all care about OpenSim - or else we would not discuss this. And I agree with Magnuz again: I also don't see the OpenSim project of today really going anywhere.

Sorry, lots of thoughts, no real answers. But I feel that it is important to express those concerns now rather than later - and to shape a new project before it actually starts, and to define its boundaries and inner workings.

Thanks for your thoughts and input, Eryn. They coincide much with my own, so I hope neither of us are very far out on a tangent.

One of my technical visions for the new OpenSimulator is creating a portal where people can search for information and report problems, and can get help filling out forms and sorting it right. Not the way it works today, where people have their heads chopped off if they happen to report a configuration error or request a feature in the OpenSimulator Mantis, or if they make an "incomplete" bug report or label it wrong. Also a team with people willing to build and maintain a knowledge database with both a good library structure and good search options accessible from the portal. The knowledge database should contain everything from basic server setup, via NAT loopback handling, to resource pointers regarding viewers, grids and content. It would be great if resources like e.g. the OpenSimWorld directory and grid listings like those from OpenSimulator, Hypergrid Business, Metaverse Traveller Grid Search or Binders World Grids Stats could be integrated.

There are already a lot of people doing these kind of things, but mostly sitting in their own corners of the metaverse and not very easy to find, especially for new users. So, much of the actual resources are there, but need to be coordinated. They also need to be compiled in a way that is not so overwhelming that people give it a glance, sigh, give up and go back to their own safe and manageable little world.

Regarding what I can contribute myself, I am still an active system developer, and even if my programming skills are not the best, I work a lot with quality assurance including documentation and code review. I guess the latter was part of what made me able to throw in a couple of thousand lines of code into OpenSimulator core within a few months after I started digging into the code base, despite I never worked with C# before.

Over the last year, I have worked mainly with infrastructure around OpenSimulator rather than in-world. The Terrains library, both on the web and in-world ( http://binders.world/terrains/ , hypergrid.org:8002:terrains ), with some 1600 free terrains is one example. Another is the Grids Stats listing, on the web ( http://binders.world/gridstats/now.html , MOAP hypergrid.org:8002:mb estates ), tracking some 300 OpenSimulator worlds in near real-time, followed up by visits to, data collection and snapshots from some 230 hypergrid enabled worlds. Before that, it was the near real-time in-world ( hypergrid.org:8002:map ) Metropolis Exlorer Map over all 4000-5000 regions of Metropolis (down now owing to some technical issues messing up the Metropolis central services) and the Metropolis video compilation, both on the web and in-world ( http://binders.world/videos/ , hypergrid.org:8002:media ), with more than 200 videos from Metropolis (resting for now owing to lack of time).

RL, I earlier worked 16 years as a (non-IT) scientist and teacher at the university, and learned both to compile, process and present large data sets in a digestible way, plus learned to coordinate and lead courses involving several tens of colleagues and up to some 100 students.

So, I guess I am a bit of Jack of All Trades, able to do both some coding, documentation, resource compilation and structuring, work planning and coordination. I do not have as much time to spare now as I had a few years ago, due to moving together with Maggie and taking on a cat, plus handling things after my deceased parents, but I spend at present approximately 20 hours per week with the Grids Stats project, much of which I would be able to divert to other projects as the Grids Stats project matures.

If this is a serious proposal, to take Opensim forward in a (more) controlled manner (and it sounds like it is), then one needs to start with a steering committee. This particular discussion has taken place here, in the Metropolis forums - one of the earliest considerations is to set the project scope (in lots of ways), for example this could be a "Metropolis" organised, managed, controlled project, offered back to the general community as a fait-accompli under whatever licensing the steering committee decide is appropriate. The Opensim system exists and "works" to a fashion, that should (could) be the best starting point. A functional equivalent with wholly restructured / reprogrammed (where necessary) / modularised code base could be an early objective. The world outside does not stop, Opensim will muddle on, SL (whoever they may be are working on Project Sansar - any "new" development must be structured to be able to accommodate change - the way we build systems today is vastly different from the way we built systems when SL was first conceived - I know I was there working (like many of you still do) building systems in the corporate world.

The modular aspects of multi-server based systems is crucial in designing a more future proof product. Magnuz mentioned interoperability with use, for example, of HTTP protocols; and such is the core to being able to farm out (perhaps) function to a variety of processing platforms where capacity exists.

Browser based UIs have a huge attraction to deploying and updating/maintaining a complex code base - putting as much in automatically updateable servers as possible to simplify end user need for a "technical" environment.

If the internal codebase structure can be "got right" there is every opportunity to move forward with satisfying "customer" expectation in a future 3D virtual world environment.

This sounds an exciting possibility, my own feeling would be to restrict the steering committee and development team to as small a group as feasible to be able to achieve the aim - I think it wholly feasible to keep this inside the Metropolis family and thus keep control and decisions firmly with a small group.

If an "aim" is to build a commercially viable system, structured to allow entrepreneurs to flourish, then I would expect the "market" to want this product rather than a moving target / failing Opensim - how it stands up as an attractive cost and functional option to SL is something that might well determine the future of Virtual world technology over the next decade.

This thread has some interesting proposals. I personally think there is still a place for a project like OpenSim, even in the age of VR. Projects like HiFi focus on VR too much, IMHO, and i think that the headsets and myriad of controllers are gimmicky and tiring to use. While it is fun to walk in the regions and see the buildings in 3D, social interaction and building is frustrating, and the novelty will wear off after a while i think. Secondlife/Opensim is simpler to use in general, and doesn't require that you learn Maya to model an .fbx for each of your fingers.

After looking at how opensim has evolved lately, i am also not convinced it is actually progressing anywhere. The developers are mostly adding contributed code from various grid. The changes are more about following the SL standards rather than building new, interesting functionality.

However we shouldn't be talking in abstract terms but try to narrow down what that project should do. Just some thoughts about what i would like in a new simulator engine; I don't know if any of these ideas are possible, but my main objective would be to simplify and focus the project:

- Built in C++ or some other widely used language (could even be python). I believe it is very important to have highly performant server. This will allow making new fun things and handling more avatars. It will make it cheaper to host regions, and the purpose would be to make the simulator as much commodity as possible. That's how web servers like nginx and apache became commonplace rather than others.

- On top of the simulator core, a snappy javascript engine like v8 could be used to replace LSL. By having a scripting language completely separate from SL, it may become possible in the future to use the simulator with other viewers apart from the SL viewers.

- All of the stuff that does not require 3d rendering and physics should be moved outside the viewer. Groups, events, money, inventory management do not belong to the 3d viewer, but can be handled by independent web sites. This will allow an independent web ecosystem to spring around the simulators. Even SL follows this pattern: in my experience, people prefer buying through the web-based marketplace rather than in-world.

In general, A new simulator should decouple itself from its SL heritage. The viewer should only be used as a 3d region renderer. I think the most difficult part is to define intercommunication between region simulators, but it is doable.

As i only have taken a cursory look in the opensimulator source code and architecture, i wonder if any of the above is possible to work with an open source SL viewer, or the extent with which it is possible with modifications of the viewer.

Also it would be fair to say that we are probably talking about a new product , and not another opensim fork. is that correct?

I just found this thread while looking for something else.
Back in about 2008 while working on OpenSim's Physics, I concluded that OpenSim would soon hit a brick wall when trying to improve its performance. 8-core server machines have kept it going, but short of moving to Crays....
Problem is C#/Mono. Its not a suitable language for a large projects like OpenSim. Go read what Microsoft says about it - for small projects that need easy platform migration.

I do think that LL got the look/feel of SL 'right' with the V1 client. Maybe not with later clients. But the way it lets residents build content, explore and communicate certainly attracted a lot of users.
The problems have always been reliability and bug fixes. In the case of OpenSim - add expansion - to support more users and land/contents.

So - I started re-writing the server from scratch. In C. ANSI C. Basically a replacement for OpenSim (or SL) that you could log into using the existing sl/os client. I called the project 'Tritium'.
It got as far as accepting multiple logins, having land you could walk around (simple physics), and being able to chat to other Avs in-world.
There are two fundamental problems with OpenSim - one is the C#/mono approach. The other is the server/client communications. My first attempt use the existing udp stream system with the piled-on repeats to attempt secure operations, so that I could use an existing SL client as-is, but I knew that a large part of SL's and OS's problems stemmed from that communication system. (Yes Philip, it worked ok for RealVideo, but VR does not care much for dropped frames.)

Having got a basic simulator working I evaluated the code and realised more than half of what I had written was for emulating the udp communications system.
So I took the next step - replacing the communications system. That requires extensive modification of the client. But I did it - at least started it, got as far as login, walking around, but stuck at dealing with the over-complicated Av 'baking' system.

The new communications use a messaging system like the old udp one but uses tcp instead. I added new sections of code to the client to handle the different format, so the client could actually connect to OpenSim or Tritium. That was useful for tracing how things worked in the client.

Then I got diverted more and more onto supporting OpenSim use. But recently I concluded again that it is unsustainable. Mono processes have no way to release RAM. They keep it 'in case its needed again'. Combine that with OO-language C#: If 40 Avs arrive in a region the simulator process grows to use 5 gigs of RAM. The Avs leave, the sim keeps the RAM. Repeat that for 10 sims on one server machine, you now have 50G or RAM tied up, out of typically 64G. The Avs continue to move around the sims and before long there's no RAM free, so sims start using swap. And that's slow. And OpenSim don't like that! Sure you can throw more RAM at it, but for how long? So once again I have concluded that OpenSim is doomed.

So back to Tritium. The client I used in around 2009 was Imprudence, but it no longer compiles on modern Linux. I have to migrate to newer client.
Also - I'm no C++ expert, assembler and C are my fields - fast and efficient. I've been looking for a C++ programmer who has the intestinal fortitude to re-write client communications, have not found one yet.

If you want to get involved, contact me on SL.

Kitto Flora