Re: Release schedule

[Nicola Pero]

> > Being compatible with Cocoa or with OPENSTEP is probably not the central
> > issue at the moment; I'm not sure why Cocoa compatibility is blaimed for
> > instability, while other stuff, such as the new text system and other
> > ongoing works (which have nothing to do with Cocoa), are much more
> > likely causes of instability.  In most cases, we can be compatible with
> > both Cocoa and OPENSTEP - since they are very similar, except for Cocoa
> > having more methods or classes (which people who don't want can ignore),
> > so deciding which of the two we are targetting is rarely a big issue
> > (but sometimes it is of course).
> 
> Actually, to a certain degree, Cocoa compatibility can be a stability
> problem. Not necessarily from a code-quality standpoint, but an important
> one nonetheless... API stability. One benefit of the OpenStep specs and
> targeting the OPENSTEP implementation is that they are a target that can
> actually be _reached_, while Apple are _always_ going to be ahead of
> reimplementations of their APIs.

I'm failing to see your point.

You claim we should target compatibility with OPENSTEP 4.2.
I claim we should target compatibility with Apple Mac OS X Cocoa 10.2.

They are both well-defined, finished products, except the a first one is a
dead product with only a few hundreds/thoudands of copies still around,
while the second one is a well-known succesfully mass-marketed product,
and there are some millions copies of it currently in use or shipping.

Unless we decide not to be compatible with anything, if we have to be
compatible with something and we have to choose between the two, it's
obvious that we should target compatibility with the second one.

I fail to see how choosing one or the other one as reference could make
GNUstep "less stable".

I know most survivors of the OPENSTEP era are on this mailing list, and
many are active contributors.  Of course we don't want to disappoint them.  
But to gain market-share, we should look at the present market situation,
and at the market opportunities.

At the moment we are a pretty solid, but small and pretty much ignored
project, barricaded around a core of die-hard supporters of Objective-C
and NeXT/OpenStep technologies.

We are here to stay - such a strongly motivated group won't disappear 
easily.

But our competitors for the GNU/{Linux|Hurd|*BSD} desktop, GNOME and KDE,
hold in practice over 90% of the market-share.  We are a tiny thing in
comparison.  We have no users as such, only developers.

It's sad that often, having the best technology around - we definitely
have the best technology around - is not enough to have the project
accepted/succesful in "market" terms.

With Apple Mac OS X we have a terrible opportunity to improve the
situation.  Apple has spent (and will go on spending) a lot of marketing
effort to sell their product.  More people know about Mac OS X than they
do about GNOME or KDE.  In the average bookshops there are more books
about Objective-C programming in Cocoa than books about programming in
GNOME or KDE.  There are likely more copies running of Cocoa than of GNOME
and KDE together.

Now if we claim *basic* Cocoa compatibility, all those boooks become
somewhat also books about Objective-C programming in GNUstep.  All those
Cocoa installations become GNUstep Trojan horses into the market - those
people using an Apple will be potentially very interested in GNUstep the
next time they turn on their GNU sytem (if they have one), or the first
time they install a GNU/Linux, or when they will evaluate porting Cocoa
apps to GNU/Unix or Windows ... or simply the next time they go around the
web and search for Cocoa resources.  All the marketing effort of Apple to
make Cocoa widespread automatically benefits GNUstep too (and we *badly*
need marketing, great technology is not enough).

Of course we need to go on writing our own tutorials, documentation,
books, code, whatever.  Of course we don't need to incorporate/track *all*
Cocoa additions - part of them can be ignored or go in separate libraries
(say, the scripting additions to Foundation); part of them can be
basically considered part of the underlying operating system and so
ignored (say, CoreFoundation, Quartz, NSMachPort) - and in general, we can
emit "recommendations" for building portable programs - "avoid these Apple
additions", "avoid those other methods", "avoid using CoreFoundation",
"avoid messing with the menu internals", "avoid messing with internals as
much as possible", "stick with the traditional OpenStep classes" etc.

But claiming *basic* Cocoa compatibility - that the average ObjC program
using standard functionality just compiles and works the same in both
environments - is a great selling point.  It's a unique selling point ...  
GNOME and KDE are API-compatible with nothing ... we would be
API-compatible with the preferred development environment of one of the
biggest player in the o/s market.

It would be criminal to waste such a great opportunity (oh gosh, I'm
really talking like a salesman now 8-).

Btw ... I wasn't surprised that the Linux Magazine article was about
"GNUstep/Cocoa portability" ... it's precisely the point I'm making - that
this is probably the most attractive feature of GNUstep for the average
Linux Magazine reader. :-)

I think it's very important that Cocoa compatibility is clearly stated in
our Mission, and in all our GNUstep web pages ... with all the
usual/appropriate restrictions.  We can claim Cocoa compatibility, but of
course with no CoreFoundation, no Apple Mac-specific stuff, not all Apple
extensions (if they don't fit/make sense we don't add them) ... we need to
keep our own personality as a project and our hands partially free - but
why missing the opportunity of claiming that we are API-compatible with
Cocoa ?

My support for Cocoa compatibility stems from my experience with GNUstep.  
We attracted a few great individuals from the free software community.  
But the vast majority of people interested in GNUstep has started getting
interested in GNUstep after coming in contact with NeXTStep, or OPENSTEP,
or Apple Cocoa.  By targetting Cocoa, we make sure that we attract as many
new people as possible from those areas.  By targetting OPENSTEP, we will
not attract anyone that we haven't already attracted, as OPENSTEP is dead
now.