Re: Release schedule

[Jeff Teunissen]

Nicola Pero wrote:

> > > This sentence directly upsets an important part of our user base,
> > > who *is* expecting us to track these changes.
> >
> > Do you seriously believe that you can track the changes to Cocoa, and
> > successfully maintain a functional product?  At the moment, from the
> > experiences that I've had, and those of others I've spoken to, the
> > most important thing at this point is having a working environment. 
> > This has been relatively elusive.

[snip]

> We are discussing general statements of principles.
> 
> Saying that we welcome Apple compatibility doesn't mean we will spend
> our development time chasing it - something else (stability) might be
> higher priority - and yet Apple compatibility, while lower priority, can
> be an important/useful thing in our wishlist.

Not if "an important part of our user base ... is *expecting* us to track
these changes."

[snip]

> But realistically, Apple compatibility is a great boost for GNUstep.

I don't believe this statement is true. It's a potential boost for Mac
developers.

> Even if we don't invest much effort in tracking the latest Apple
> changes, we must recognize that being Apple compatible makes GNUstep a
> lot more interesting and attractive.

Ditto. I don't think that GNUstep really gains ANY attractiveness by being
Apple-compatible. Windows compatibility got OS/2 users the ability to run
Windows programs, but killed the market for native apps. Once that mistake
had been made, IBM couldn't withdraw Windows support...because there were
no native apps. Today, most of the stuff running on OS/2 is ported from
Linux using the EMX runtime library, run by a tiny community of diehards.

Why do I think this is relevant? GNUstep has relatively few users and
developers. We have some "native" apps, but not enough to provide a full
user environment yet. Porting Mac apps helps from one, narrow, perspective
-- more apps. But those apps are not "native". They work like Mac programs
transplanted into a different environs -- they don't work like a true
GNUstep program "should".

This wouldn't be a big problem if the GNUstep community were healthier on
its own...but by putting lots of transplanted Mac apps into the system,
suddenly Mac stuff isn't the odd man out...it's the native stuff that acts
"wrong". End result? GNUstep becomes nothing more than Cocoa for non-Mac
platforms...and that's a shame.

This problem doesn't exist with GSWeb/GDL2. It's the user-level
environment that needs to be protected against "invasion".

> So, I'd suggest to keep balanced when writing such statements of general
> principle - while developing a superior free product is our main
> objective, being compatible with Apple can be a strategical win and help
> us to reach our main objective by making our free product look more
> attractive in real-world terms, and enlarging our user (and contributor)
> base.

Making GNUstep compatible with Apple will do nothing more than force you
to forever try to keep up with it, because starting down that path will
keep GNUstep from acheiving its own independant developer/user
community...it'll be dominated by people whose only use for GNUstep is to
port their proprietary Mac software to the bigger Linux market. There will
be no one to stand up to the guys wanting more, more, more, just like
Apple, we want a clone.

GNUstep can prosper on its own terms, by taking a stance to be separate
and good, while cherrypicking some of the best ideas from other
environments (including Cocoa).

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/