> c. If ports for other hardware consoles (PS2, XBox, etc.) are created,

I've been lurking here for a while, and can affirm that NetBSD ports to 
new hardware seem to be considerably less difficult than one might 
imagine, given how tightly most of us are bound to ``desktop'' computers, 
or how many ``Internet Appliances'' are disguised PeeCee's, or the 
colossal fanfare and pressrelease hornblowing surrounding a new port of 
RedHat or Debian GNU/Linux.  They usually only take a couple months to 
become useful, _if_:

  o The CPU has VM.

  o More than one person is interested in the result.  Three or four 
    people seem to be plenty to pull off a port all by themselves.  
    This is obviously not a problem for the PS2, but maybe for the XBox.

  o The device itself is obtainable.  This is difficult with PS2 if 
    you do not have Japanese citizenship, since Sony enjoys considerable 
    protection by the Nipponese government.  

    XBox does not exist and could be cancelled at any moment from some 
    business strategy market model redirection necktie-damage.  This has 
    happened with one device to which NetBSD was ported already, and the 
    decision involved the same technically-suspect markedroid company.

 -and-, [drumroll]

  o The device is documented.

    The DC is unique in this respect, because I think maybe Sega does 
    not have the technical/legal power to mask their own CPU's, so the 
    SH4 chip has documentation from Hitachi.  Also, Sega has elected 
    not to use serious cryptographic obfuscation techniques, expensive 
    legal threats, or government lobbying to turn their meatspace 
    devices into protected so-called ``intellectual property''---
    consequently, some independent hardware docs for DC exist, and 
    will probably have the freedom to develop further.

    While there is a fairly good chance that any sort of ``cryptographic 
    obfuscation'' on the XBox will be broken to the point of 
    meaninglessness just like ``domain authentication'' and ``PPTP,'' 
    I think documentation will be harder to get for the PS2 and XBox 
    than for the DC.  but that is just my opinion.

    This is Critical.  Ports seem to be made to documentation, not to 
    hardware.  Ex., this is plausible: 

      ``I got low-level documentaiton for Device X, want to do a port?''

      ``Sure!  How hard is it to lay your hands on an X?''

    while this succeeds far less often than one might think--amost not at all:

      ``I got 20 free Y's!  want do do a port for me?  I'll give you 
        half of them.''

      ``Sure!  How hard is it to find correct documentation for a Y?''

> in theory, could this indie developers create NetBSD console games 
> that run on any NetBSD supported system?

What a foolish idea.  Why would anyone want to use working thread 
libraries, Mesa GL, and first-rate compilers in a proven embedded 
operating system that runs on all the major game consoles and all 
the major ``desktop'' computers, when the person could simply write 
their own version of these things, and write them repeadedly, once for 
each proprietary console, and twice again for Mac and PeeCee?

seriously now, it seems there is a gigantic financial incentive for 
console companies to prevent NetBSD from creating a port to their 
hardware, and the price of their success is passed directly onto their 
customers in the form of more expensive games that bear the ``Sony Tax.''

This is terrible for NetBSD in general, not just NetBSD on game consoles, 
because so much bleeding edge technology goes into making games.  Rather, 
I think we would like this financial incentive to pay for free(ly 
available) contributions to NetBSD for things like a fast, light, 3D GUI 
layer; or our SMP/preemptibility work; or a good FLASH filesystem; or (my 
favorite, a longshot) toolchain improvements on notIntel CPU's, like clisp 
on netbsd--mipsel or proper C optimization on arm32 or some more assembley 
primitives for libm.  

These are all things that game companies will probably have the money, 
expertise, and inclination to contribute to NetBSD.  I can envision a 
gaming company being more interested in getting free support for such 
improvements than depriving their competitors of their work, because the 
work is so tangential to their ``product''.  These improvements are also 
things that will be a godsend to other NetBSD users who are not game 
companies.  so, this scenario is an example of code-sharing that is 
uniquely enabled by the sometimes-dubious BSD license.

However, NetBSD and the hardware manufacturers are fighting over the 
same wad of cash, albeit indirectly.  If the game companies have to 
pay the Sony tax, they will use the Sony toolkit.  If NetBSD is an 
option for them, then they will have this additional budgeted tax 
money freed up to improve the NetBSD toolkit to meet their needs.  
My hopefully-mistaken gut impression is that the Sony Tax is basically 
what Sony is depending upon to ensure their solvency over the next five 
years, so I think ``why can't we all just `get along,' and both 
Sony and NetBSD can win.  no, really.  The best way is to make 
`relationships' with companies---it worked with Digital, so it'll work 
with Sony.'' is going to be the Lemming Option for NetBSD.  see, (1) It 
didn't, exactly, ``work'' with Digital, remember? and (2) Sony is a very 
different kind of company.  I'm not even sure Sony _is_ a company any 
more.

so, it's war.  Any ideas on how to insure that we win and they lose?