Archive for the ‘Rants’ Category
The Finite Manpower Problem: Or why we suprisingly cannot do everything at once
I’ve been afflicted by this very problem myself lately, which is why this post has been sitting in my head (along with a slight hangover) for the last few days.
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.
Oh look, Vapourware!
Let’s run through the quick checklist for the recently semi-announced “LivePlace“, who claims to do some pretty nifty things with distributed server side rendering.
- Buzzwords like “Cloud Computing” and “Virtual Worlds”? Check.
- VC Capital Funding? Check.
- Implausible Technology that doesn’t stand up to basic analysis by an industry professional? Check.
Say hello to serverside cloud based renderered virtual worlds. Somehow, against all odds a small unheard of Silicon Valley company has developed a real time renderer that not only exceeds the current best of breed distributed real-time rendering research projects by huge margins - does so in a way that’s scalable to deploy a major concurrent project on.
Doesn’t anyone in Silicon Valley do basic fact checking with a technical adviser before giving capital?
Assuming this company has actually succeeded in developing such a renderer (big if) isn’t there the additional problem of bandwidth? Let’s be kind and say the average user has a 1024×768x32 screen - that’s 24mbit of data that needs sending 30 frames a second (720mbit/sec), now yes you can use some video encoding to cut that down significantly - but that’s a heck of a lot of data, and the compression is going to induce processor load seizures too.
The answer to the above question is apparently not.
There is a big reason we do client-side rendering today, and that is it distributes the load better than any “cloud”. 100,000 clients = 100,000 processors, 100,000 graphics accellerators, etc. Yes some of them suck and can’t do pretty graphics (Intel I’m looking squarely in your general direction), but the rendering they can do is going to be better than what a foreign service can do for you, and it’s going to be speedier - not only do you not have to wait 200ms ping and a x megabyte download to happen before you see the results of your movement.
While I am not claiming that this technology couldnt be made to work - it’s just not going to be pretty, I dont believe it will scale anywhere near effectively, and the bandwidth requirements alone are going to cause some very tough questions to be asked about whether this will run at all. (After all - anyone with a internet connection fast enough to support this is going to probably have a decent video card anyway.)
Count me very skeptical.
Shouts to Belaya for adding to the snark contained within this post.