Adam Frisby

The Finite Manpower Problem: Or why we suprisingly cannot do everything at once

with 2 comments

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.

Written by Adam Frisby

September 12th, 2008 at 5:25 am

2 Responses to 'The Finite Manpower Problem: Or why we suprisingly cannot do everything at once'

Subscribe to comments with RSS or TrackBack to 'The Finite Manpower Problem: Or why we suprisingly cannot do everything at once'.

  1. Ever read The Mythical Man Month? While written in 1975, it still has a lot of valuable lessons for software engineering today; highly recommended.

  2. Bravo! Well worded and one of the best summaries of a solid open source project I’ve read. And FINALLY someone is not afraid to mention money in the same breath as a project, so score one for an honest treatment of a project with solid business potential.

    It’s a peeve to me that open source is so obfuscated to the layman and the average person. One of the most retarded statements I’ve ever heard was “free as in speech, not as in beer”. It isn’t deep, witty or even clever and it just serves to confuse Joe Average even further that open source in many cases is a business model (blanket statement I know).

    I love open source, but to Joe Average it’s often seen as this philanthropic goodness where coders are willing to bend over backwards adding free features and when the bubble is burst seen as a hypocrisy masking “free labor”. We know hardware, bandwidth and valuable developer time don’t appear out of the ether. So again, thank you for a clear, non veiled and kindly explanation of the subject.

    TMahoney

    12 Oct 08 at 4:23 am

Leave a Reply