The three questions we will ask of the database are; “How many unique users logged in in the last day? week? month?” – of the 10,958 who have at least one recorded login in the last 6 months since we added the field, 468 logged in today, 1,142 this week and 2,822 this month. The next question to ask is – how does this break down across by signup date? The following highly compressed chart shows the information for the number of logins in the last 24 hrs, 7 days and 30 days from each signup group. (A signup group is all the users who signed up in a certain calendar week).

Fig 1. Logins versus Signups

You can still pretty distinctly see the point at which Linden announced OpenSpace price changes (Y2008W41), but it doesn’t quite explain if these users are sticking around more, less or the same as users who signed up beforehand. We’re expecting some kind of drop-off since a lot of users were just experimenting with alternatives – and we’re not really focusing on being a SL clone (unlike some of the other grids). So, the next chart shows the above data – but divided by the total number of signups in that week.

Fig 2. Signups versus Logins Proportionally

I clipped off some of the earlier data since it was giving erroneous values, but what is interesting here is that older users have a fairly incredible retention – >30% of users who signed up in 2007 / early 2008 are still around and logging in. Newer users have dropped off – but there’s still a pretty high proportion who stayed – both myself and nebadon believe these might be region operators – early users were all region operators, and region operators probably have a pretty good retention.

So let’s take a look at some more data – the following is logins from the last 30 days – how many are region owners (cross referenced against signup date)

Fig 3. Region Owner versus Logins

Now this is a little incomplete, since it wont measure things like estate managers – it only shows people who are the registered region owner by the Master Avatar parameter. There is a trend for people with older accounts who still login regularly to be more likely to own a region – but it’s not absolute.  Looking at this data you might be mistaken for thinking that newer users are less likely to own a region – but charting the data % of region owners by signup date you get a different picture.

Fig 4. Proportion of Region Owners

In conclusion – the data seems to indicate mixed results to the original question; users who signed up looking for an SL alternative are more likely to have left than users who joined beforehand – but trends seem to be indicating the core underlying growth is still pretty strong; and a healthy percentage of the people who did sign up in that period have stuck around – overall growth of active users increased by between 200 and 600 percent after that jump.

There is also a trend that the more active users are region owners – of the people who logged in in the last 24 hours (versus 30 days for Fig 3), closer to 50% were region operators. This doesnt strike me as too suprising given that OSGrid’s real strengths are in the ability to connect in regions free of charge – more active users are more likely to b involved in that aspect of the grid.

For other grid operators who are interested in calculating the same numbers I have above for comparison, on the next page are the horribly complex SQL queries I have been utilizing to generate this data. They should work with any OpenSim-standard MySQL installation. Click here to see them.

As seen in Adobe Illustrator CS3

That is all.

It should go without saying that a single developer can only achieve X number of features/fixes/improvements in Y time (and not every value of X is equal), but the moment you substitute “X” with specific feature names, it suddenly becomes urgent priority for everyone to stop work on it and get that done, to hell with everything else – although we want that too … and a pony.

The facts of life

The reality is – we’ve got a finite number amount of time, a finite number of developers, and a not-quite-so-finite list of features and improvements we have to spend time on, this means we prioritise stuff. We say “We think stability is a prerequisite before you go about implementing an example micropayments system.” – and with good cause, if the system didnt have that prerequisite stability, why the hell would you trust it to handle important or sensitive information?

This is not to say some of us havnt devoted time to thinking about it, it’s just that we each have our own ideas about what we think is important, and unless you are actively assisting in some capacity (food, booze, code, testing, etc), your personal wish list probably isn’t going to get any attention.

It’s harsh – but there it is. At the end of the day, each developer has a finite amount of time to work on projects, and when they are working on things – there is a strong chance that a specific goal is in mind and needed. If you want to change that goal, you either must have a convincing reason that that person is interested in and agrees with, or you need to provide an incentive to compensate for time that would otherwise be spent elsewhere. It’s also quite possible to just get in there, and do it yourself then submit those changes back.

Backseat Driving

There’s a lot of developers working on the OpenSim project – and each of them has their own ideas, goals and projects. Some of them are working on commercial projects that rely on OpenSim – and hence have some very specific feature and stability requirements that they work on. Others have more free reign by virtue of doing this in their spare time. There is a common misconception that the OpenSim team has an agenda – there’s somewhere around 200 developers on the project which means there’s 200 sets of agenda’s.

Right now, my personal agenda (which by proxy does carry a little across to what the DeepThink developers are working on) looks something like this:

• Abstract login and client initialisation to a more generalised interface to allow third party login and authentication routines to be fitted more easily as loadable DLLs.
• Find where we have remaining hard-coded references to LLClientView bits and bobs, and recode them in a more vendor neutral manner.
• Have a look at some of the terrain control issues reported on the mailing list recently.

It’s a pretty short list – this list gets revised, updated and changed pretty regularly based on what I need to do at the very moment, it’s the same for a lot of the other central developers – they are built on a task-by-task basis.

So – if you have a feature you really want to see happen, that you really think is important we tackle and address, your options include:

• Do it yourself – the code is there and we dont bite when it comes to new contributions. (Just as long as the code matches our other guidelines about quality, modularity, etc.)
• Convince someone to do it for you – this it the hardest of the options since we’re already very busy as a group, but it’s certainly possible. Make a convincing argument – it helps if you can research it and break it down into specific tasks. (”Improve stability” is not a task – “Fix crashes when/while XYZ happens” is.)
• Hire someone to do it for you – it’s an option on the table too. There’s a lot of developers familiar with the codebase now, lots of them are looking for beer money and can implement your pet project or ideas for a fee.

So in conclusion – if you have something you really think is important, really want to see – think it through, ask yourself “Is this more important than what people are working on already”, “Is this something that OpenSim is ready to support”, “Is this important enough that I am willing to work to see it done?”, and finally “If no-one thinks it’s that important, ready or <insert reason here>, am I willing to pay to see it happen?”. Because at the end of the day, features take time, and time is a non-renewable resource – people like to see it invested wisely.