Pros and Cons of Middleware

Coding

Whether you're a high end game maker working on a multi million dollar project, or an indie developer making a game for fun, you'd be very wise to consider what 3rd party systems you can leverage to save you time. Spending a little time to investigate what systems you can use could save you months or years of development effort.
High end commercial projects often license non-cheap systems for rendering, physics, sound etc (e.g. Renderware, Havok, Miles), while indie developers can use cheap or free systems like Ogre, Newton and OpenAL. Both at work and at home I like to look at the different systems out there just to know what's going on.
There are pros and cons to consider. Here are a few of the main ones which would face an indie developer:

Pros
1. Save LOTS of development time!
Taking the example of a rendering engine such as Ogre or Irrlicht. Using a system such as this usually gives you a well thought through and efficient system, which comes with advanced features like exporters, viewers, example code etc. If you attempt to build this yourself will take you far longer than it would to integrate and learn another system, and you'd also unlikely reach the same level of features.

2. Systems are debugged well due to the number of users.
Because open source systems have a lot of users, they tend to be pretty well debugged. The users will be developing in different operating systems, with different compilers, and different hardware. In terms of rendering engines, it's great news if you can be confident from day one that your rendering code has been tested on a broad range of hardware. Also note that the source will normally have a 'stable' branch, and a 'development' branch. The stable branch just gets bug fixes. The riskier new features go in the development branch.

3. You can use features you wouldn't otherwise use.
Engines often come with advanced features which can be easily 'turned on'. It can be trivial to turn on features like audio echo, stencil buffered shadows, full screen 'HDR blooming', etc. You may not have initially planned to need these features, but they can greatly enhance your game with very little effort.

4. Joining a community of developers.
All commonly used engines tend to have a wiki and/or forums to help you use the system. It's even more rewarding when you start to write your own wiki pages and help people in the forums. When you look back at a wiki page you wrote and see that several thousand people have read it and been helped along, it's a real buzz.

Cons
1. Reading licenses
Not so much a Con, but something you'll need to cope with. Each library comes with a license. This might say "do what you want with it", or it might say "don't modify it, and use it only as a DLL", or "You need to show our logo when the game starts" etc. The slightly annoying thing is that they're written in legaleese and distilling the meaning and looking for gotchas can give you a headache. Also look out for one system using another system, and you needing to read the licenses for the subsystems too. Examples of this are a rendering system using someone elses XML reader or true type font renderer. All this said, if you're just doing demos for your own ammusement, then you can usually just ignore the licenses (though that's not legal advice:)

2. Getting things working can be tricky.
Sometimes you get lucky, and sometimes you end up pulling your hair out. Installing all the right downloads to the right places, getting the right versions of everything, setting up project settings, and deciphering wierd crash bugs can be part of the territory when trying to get the first version working. That said, even if it takes you a couple of weeks to make it happy, you're still likely to be well ahead compared with writing it all yourself.

3. It may not do exactly what you want.
Third party systems, including commercial ones, will often 'like to do things a certain way', or more specifically 'make it really hard to do certain things'. When faced with something like this, either make sure that the system has the feature before you get too attached to it, or be ready to bend your requirements to fit better with what the system is capable of doing. For example, you might want to use Milkshape to build your models, but the system only comes with a Blender exporter - you could either change your choice of render system, join in with the development effort and make the new exporter, or just suck it up and learn the new program...

4. Getting new versions can be a pain.
Generally it's best if you get a version which works well enough for what you need, and then stick with it until you're done. Unfortunately you'll often need to upgrade. This can bring with it problems like needing to upgrade compiler, your data files being of an old format, the API changing, and new bugs being introduced. If the system has sensible people at the helm, these problems will be minimized by ownership of the system staying constant, version numbering which makes it clear whether to expect API changes, seperate branches for stable and release builds.

Tips for Choosing Systems
1. Get recommendations from friends/sources you trust.
2. Download the samples and try writing a simple demo / playing around with it before diving in and integrating it with your code.
3. You could use web traffic monitoring information to gauge how many users a system has. If, for example, Google Analytics shows low traffic, then it might mean that it's not a very popular system. Though that said, a system might get a lot of traffic if everyone is having trouble with it :)

This is quite an interesting topic, and I've only managed to unevenly scratch the surface here. I'll return to this topic in the future, and also detail some experiences with specific systems. (To avoid any legal issues, I'll talk mostly about non-commercial products)