[MUD-Dev] re: Sun's Sim Server and Gordon's 10 Reasons (thefirstone :))

[Mike Rozak]

Tess Snider:

> The middleware folks have their heart in the right places.  Let's
> get all this technical nonsense out of the way so that people can
> do content generation!  The universal problem with all middleware,
> however, is the flexibility/work tradeoff.  That is, the more
> flexible the middleware is, the more work the buyer has to do.  If
> they come after you with an "It slices!  It dices!  It even does
> RTSes!" routine, you're going to have to do a lot more than
> content generation to make a game out of it.  Alternatively, you
> end up with a constrained system, as Raph was explaining, and you
> may not be able to use it to make the game you want.

This is one problem with middleware. There is another equally large
problem not mentioned so far:

When I worked at Microsoft and had to deal with middleware, we found
it quite scary...

  1) What happens if there's a bug in the middleware that prevents
  your MMOG from shipping? Obvious soln: You include bug-fixes in
  the contract. (My group had this happen, although the project had
  nothing to do with MMOG.)

    1a) What happens if your middleware provider ends up being
    somewhat incompetent... not doing source code management, bug
    tracking, or making lots of extra fixes 1 week before ship (even
    though they claim they only made one minor change that you
    requested)? (Don't forget, the middleware provider is also
    selling their middleware to other MMOGs, some of which are many
    months away from shipping and which have requested large feature
    changes.) (My group had this happen.)

  2) What happens if there's a bug in the middleware and the company
  that produces it is unwilling/uncapable of fixing it? Soln: Ammend
  the contract to keep a copy of the source in escrow so that if it
  comes down to the wire you can access it. (My group had this
  happen.)

  4) What happens if 1.0 ships successfully but sometime before you
  start 2.0 the middleware vendor goes belly up? Do you a) pay money
  to buy the rights to the middleware vendor's source code, or b)
  use another vendor and change all APIs (and assumtions) in your
  code that used the middleware. Option a) costs money, option b)
  will slip 2.0.

  4) What happens if the middleware vendor sees how much money
  you're making and decides to up their royalties for any features
  you request for 2.0?  Again, you can either pay or rewrite your
  code to use some other middleware.

  5) What happens if the middleware vendor is purchased by a
  competitor? They may follow the contract to the letter, but you
  can bet they won't provide you 2.0, 3.0, etc. versions of the
  middleware. You'll be forced to rewrite your code to use a new
  middleware layer.

  6) What happens when you, in turn, want to license out your entire
  MMOG engine as middleware? You'll need to watch out in the
  contract to make sure you can sub-license. (My group had this
  happen.)

  7) If your MMOG is made of entirely middleware, what value added
  do you have? (Ie: The more middleware that's out their, the easier
  it is for a competitor to emerge. The more competitors, the less
  money you make.)

  8) What happens if your middleware provider uses the annuity
  they're earning from you to finance their own entry into the MMOG
  environment and end up competing with you (while selling you their
  middleware at the same time)?  (My group had this happen.)

As a MMOG (or any company), your response will depend upon where you
see your own product going:

  a) If your product is a one-off then always use middleware.

  b) If your product (and codebase) needs to last years then avoid
  middleware like the plague... except under the following
  circumstances:

    - If the middleware conforms to an API that is also
    well-supported by other middleware then the middleware is easily
    (hopefully) replacable. (Ex: Speech API, video/audio drivers,
    SQL.)

    - If the middleware is from an established company that isn't
    likely to go bankrupt or get sold, then you're reasonably
    safe. (Example: Use of Orcacle's database, or Micorsoft's
    database.)

    - If the middleware is open-source then your reasonably safe
    EXCEPT open-source code sometimes has licensing issues that may
    make it difficult to license your entire product at some later
    date.

PS: If you design your own middleware API and get a middleware
vendor to modify their codebase to support the API (as opposed to
your software using their API) then you can also pay a backup
middleware provider to port to your API. (Conversely: If you use a
vendor's API you may have legal problems if you get a backup
middleware provider to use the original vendor's API.)

Mike Rozak
http://www.mxac.com.au
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev