Fwd: The PenguinPlay project and the name controversy

[Christian Reiniger <warewolf@mayn.de>]

Hi,

This evening I got a surprise mail that, well, shook me quite a bit. (Seems
as if we found the big topic for next weekend's meeting, Adrian...)

Please read it carefully and think about it even more carefully.

----------  Mail forwarded (Author is Charles Durst)...  ----------
Subject: The PenguinPlay project and the name controversy
Date: Tue, 18 Aug 1998 17:35:14 -0400 (EDT)
From: Charles Durst <cdurst@world.std.com>


I've been thinking about the discussion from the last IRC meeting, and I 
wanted run a couple of ideas by you in private rather than sending them
to the whole list and risk being flamed for them.

[Of course I asked him before posting]

Perhaps the whole question of what to call the Unified Linux Games
Project should simply be bypassed as follows (even though it would mean
altering the purpose of PenguinPlay significantly).


As described on the PenguinPlay web page:

    The goal of the PenguinPlay GSDK project, is to provide the best
    working environment to create and port game and multimedia
    applications to the Unix like operating systems.

As described in Adrian's Overview attachment:

    The PenuginPlay project is an attempt at creating a free (open
    source), comprehensive, cross platform toolkit for developing games
    and other multimedia software. Our goal is to make it easy to
    produce a broad variety of high quality games and deploy them across
    platforms. (While our primary development platform is Intel based
    Linux, we indend to port to other Unices and Win32. DOS, MacOS and
    Beos are possible too).


What I'm suggesting is to change this purpose to something more along
the lines of:

    The goal of the PenguinPlay project is to act as a clearing house
    for information and free (open source) software to support creation
    of comprehensive, cross-platform toolkits for developing games
    and other multimedia software.


The idea being that PenguinPlay would not be the name of ONE
comprehensive toolkit, but rather the name of a project to:

    * Help coordinate communication, compatibility, and "glue" software
      between existing and new (mostly external) Gamedev library projects.

    * Helping to fill the gaps that are currently preventing any
      combination of GameDev library from being comprehensive enough.

    * Help to direct game developers to the right tools for their
      particular tasks.  Making it easy to find software for a
      particular purpose, within certain license requirements.

    * Collecting the general feedback that Game Developers might want to 
      give the Linux community about the porting problems they (might)
      have.  And helping to start, extend or fix projects to meet those
      needs.

    * Helping rally Gamedev library development efforts to port existing
      game libraries to needed, unsupported platforms.

    * Helping Gamedev library development efforts communicate with one
      another, and share algorithms and code, and perhaps to help them
      abstract out new layers of common or overlapping functionality.


In essence I suppose I'm suggesting that PenguinPlay become more of a
meta-project.  Kind of like Debian is in relation to the packages it
collects.  Encouraging the development of free tools.  Collecting
easy-to-find and easy-to-install packages of game SDKs and trying to
make it easy for a new developer to choose the one(s) that best meets
their needs.  Helping with bugfixing, porting, and documentation
(especially w.r.t. interoperability between projects).  Perhaps even
helping develop policies to ensure clean interaction between libraries
wanting to be added to the collection.


As for the current PenguinPlay sub-projects, you could either "spin them
off" and just treat them as any other projects would be treated, or
contribute them to other teams.  It might even be possible for PP to
keep them and consider them "glue" or "alternatives" -- as long as they
didn't get any sort of preferential treatment in the project listings.
(These listings would have to be open, honest, and accurate
representations of the current state and usefulness of each project.)




If adopted, this idea would completely remove the question of whether to
rename ClanLib or other packages.  It would remove a lot of the
political problems involved in the appearance of coming in and "taking
over" control of existing projects.

PP could still encourage a joining of existing projects if it makes
sense to the participants (e.g. pp2d, GAMES, SDK etc.), but the end
result would not be considered the "one true" GSDK, but just another
library to be considered by game developers looking for tools.

In the end, there would still be multiple, competing packages, but
that's OK as long as at least one comprehensive open-source solution can
be cobbled together from the pieces.  As we have seen with multiple
distributions, and even the KDE/GNOME projects, competition can
sometimes be a very good thing ... if you can see past the flame wars.

The biggest problem with having multiple, competing projects is the
resultant (developer and user) confusion.  What I'm suggesting is
that perhaps PenguinPlay should be aimed simply at reducing that
confusion by helping people find, evaluate, combine and use the
available tools, or develop new, missing ones.

In fact I wish that the KDE/GNOME war had such a higher-level project
trying to make sure that they cooperate on key interaction technologies
like Drag-and-Drop, file/application associations, etc..


Anyway, it's just a thought, and I'm just presenting this as a
"straw-man" proposal.  Please let me know what you think.


Charles Durst          .------------------------------------------------.
=======================|  cdurst@world.std.com                          |==
                       |  http://www.tiac.net/users/cdurst/cdurst.html  |
                       `------------------------------------------------'

P.S. - It's looking like I can't make this Saturday's meeting ... we're
having a company Clam Bake that day.  Yum!

---------- End Of Mail ---------------

Just a few notes from me:

* Such an approach means more work than with *one* project (merged SDK)
* If we go this way we should start a big public discussion soon (in fact
it would be pointless to further delay such a discussion then).
* In the long run, this approach seems to be, well, cleaner than what we
currently planned, more scalable, flexible perhaps

Well, I don't know yet whether I like or hate it....

Cu
	Christian
--

Hiroshima 45 .. Tschernobyl 86 .. Windows 95