RE: So let's get right to the point

["Brandon J. Van Every" <vanevery at indiegamedesign dot com>]

Lincoln Peters wrote:
>
> I'm not going to try to take sides, but I will try to answer some of
> these questions

Lincoln, thank you for taking the time.

> (although none of them make good multiple-choice questions).

It's a better multiple choice quiz than you might at first think.  I'm
laying out some requirements for me to do certain things.  But, I'm open
to the possibility that some of my requirements may be overly narrow.
If people have a way of addressing my concerns, I'll listen to them.

> > 1. Python required in the kernel
> > a) yeah, that's awesome!
> > b) hell no.  Go away.
>
> I don't think Python is required,

If I am to do "hodgepodge OO migration" for/with you guys, it is
required.  And it must be in kernel.  "It's not required" is synonymous
with "thanks for offering, Brandon, but we're not ready to move on
this."  If I do the work, it has to be in my preferred language, and it
has to be forcibly stress tested by anyone who runs Xconq.  I see no way
to achieve these 2 objectives other than "it is required."

I am not excluding the possibility of interop solutions with other
languages.  I am saying, if I am working, there will be Python and it
will be required for Xconq's operation.  Others might make similar,
reasonable demands regarding C++, Perl, or whatever.  But equally, they
will need to provide the interop solution.

> but Python would make it easier to do
> things that are difficult or impossible right now (which have already
> been discussed over the last few days).  And it might improve Xconq in
> ways that we can't predict now.

Yes, I agree there are many benefits to Python.  I think it will be an
easy sell once you have example code doing something in kernel.

> > 2. Kicking 7.5 out the door so that new features can be added
> > a) yeah, any week now!
> > b) I want my months before you even think about touching my
> source pool.
>
> I think that it's quite clear that we all want to fix as many bugs as
> possible before releasing 7.5.  Although it seems that we're getting
> close.

Well, here's the rub.  What's your timeframe?  I'm a businessman, and
I'm not interested in waiting.  Certainly not in waiting indefinitely
for when someone "might" kick 7.5 out the door.  For me it's
unacceptable to have a bottleneck like that in my critical path.  If
you're going to Do something, you Do it.

Are you amenable to forking the source?  A stable bugfix release, vs. a
next-generation-let's-get-started release?  It's what people often do to
overcome this sort of problem.

> Remember, open-source projects (usually) do not have marketing people
> screaming at them.  Xconq 7.5 will be released when it is
> ready, and not a moment before.

If that's your shipping culture, we won't be able to conduct business.
It's not aggressive enough for a comercially-oriented developer such as
myself.  Also, it doesn't inspire people or keep the project growing.
What I've been hearing is that people would like to see some of these
Python features, but I doubt anybody's getting excited about waiting
until 6 months from now to see them.

> A lot of software companies (especially Microsoft)
> could have saved themselves a lot of trouble by working this way.

You've gotta be kidding.  If you believe that, you totally don't
understand the Microsoft release model.  I live in Seattle, and I do, as
do most people around here.  Microsoft deliberately barfs the first
version.  They put it into the field and force the customers to find the
bugs, that's part of how they make money.  They use aggressive marketing
to push their early crap.  The first version of any Microsoft product
sucks.  The second one is so-so.  The third one is ok.  The fourth is
often decent.  The fifth is usually pretty good.  Pretty soon, nobody
can possibly catch up to the combo of their technical improvements +
their marketing mindshare.  It is one of the main methods by which they
have conquered the computer industry.

I don't know any commercial developer who takes the attitude of "sit
back and wait."  That's a hobbyist idea.  If the disconnect is too
strong here, that's ok, we'll go our separate ways and no hard feelings
on my part.

> I don't think that anyone is worried about you "touching our source
> pool" beyond that you might introduce something that has unexpected
> results.  That's why anyone with CVS access tests a piece of code as
> thoroughly as possible before committing it.

I'm on board with that culture.  It's what we always did at DEC, and we
achieved the highest level of OpenGL Conformance in the industry at the
time with such methods.  I always apply fascist testing and source
control methods in my own work.

> > 3. Recruiting a horde of Windows C# .NET developers
> > a) the more the merrier!
> > b) get out of here you Micro$quish suckup bastard
>
> "Micro$quish?"  That's a new one.

Not really, it's common.  Try Googling for it, albeit without the $.

> Although I
> suppose that it would make it possible to add lots of new features to
> the Windows version, I would be reluctant to add anything
> that would not work on all Xconq platforms.

C#, .NET, and Microsoft-specific stuff is not my first priority.
However, considering how aggressive I am once I'm doing something, it
may come up sooner than you'd guess.  It's how I'll be writing GUI code,
when / if I'm ready to do that.  Also, putting on the "cheerleader" hat
I'll be trying to get people with the Windows mindset into your project.
If you don't really feel "the more the merrier," if that actually makes
you squirm in your chairs, we'd probably better know that about each
other's attitudes and intents up front.  In that case, it would be
better for me to depart and lead a Windows-centric project.

> For example, I would be willing to add
> code to Xconq that would let it talk to MS Excel, but only if it was
> possible to do the same thing with at least one other spreadsheet
> application (e.g. Gnumeric) on other operating systems (e.g. Linux).

I can help you with things needed for .NET / Mono interop, but you would
have to be point man for Mono.  For instance, I'm not setting up a Linux
box.  And, you should understand that language interop is my agenda, not
cross-platform implementations for everything in Xconq.  If Python runs
in kernel on all platforms and C# .NET implements a Windows-specific
GUI, my needs are spoken for.

> Getting back to your question, if a horde of Windows C# .NET
> developers
> could make a contribution to Xconq without causing problems
> in the UNIX
> and MacOS versions of Xconq, I'd be inclined to welcome them.

I think that's a simple matter of separating kernel concerns from GUI
concerns.  I'm not saying C# should be in the kernel.  My view is, C# is
going to be the preferred language for Windows GUI programming for the
forseeable future.  Meanwhile, Python is to be preferred for platform
independent code, AIs, and game design scripting (if you guys decide to
augment or replace GDL).

I am evolving a hybrid Python / C# business model, you guys are my
guinea pigs.  :-)

> Are the answers I provided firm enough?

Yes I would say so.  It remains to be seen what other people's opinions
are, and what the dominant consensus of your group is.  And also,
whether Eric wants to raise enough of a stink about anything to
effectively exert "veto power."


Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

Taking risk where others will not.