project goal Re: Release schedule

[Helge Hess]

Moin,

... getting a bit late into the discussion, had to do some real work ;-) 
Started the mail yesterday and still writing on it (quite an amount of 
other mail came in in the meantime) ...
Find below a huge stack of junk I wrote in an attempt to bring up my 
idea of what an ObjC/Foundation based project could be.

Nicola Pero wrote:
> I frankly fail to understand why AppleScript, Quartz, NSQuickDrawView or
> NSMachPort are relevant anyway to API stability.

I think I understand the issue even though I do no agree. Actually as 
far as I can see two different perspectives are take place in the 
discussion:
a) a technical perspective
b) a resource perspective

From what I've seen so far people always take only one of the 
perspectives in the discussion, even if this isn't always apparent ... 
which results in misunderstanding (obvious if you take a look at the 
huge thread).

IMHO (attention, *everything* below is IMHO ;-):

a) does Cocoa add any *technical* instability or complexity ?
No, absolutely not. IMHO Cocoa scripting classes and even CoreFoundation 
*should* be added to gstep-base/gui to improve compatiblity. If you 
don't want Scripting, don't use it, if you consider it instable, don't 
use it. Almost anything in Cocoa are *additions*, not incompatible 
changes affecting OpenStep compatibility.
This is what Richard, Nicola, ... are talking about and they are right 
from this perspective.

b) this point is a bit more difficult to explain. Does Cocoa add 
instability ? Yes ! Because GNUstep has *extremly* limited developer 
resources. So it's very important to focus on a project which actually 
can be accomplished in good quality using the given resources. For 
example if Nicola would have invested the same time in gnustep-gui like 
in Renaissance, GNUstep GUI itself would have probably much further now 
! Now we have a good Renaissance on MacOSX (which I like ;-), and a 
lacking one on Linux because gnustep-gui is simply not stable.

The Problem is, that b) cannot really be enforced in free software 
projects. Same example, if Nicola want's to write Renaissance instead of 
investing the same amount of time into boring X11 testing and fixing, he 
will do so.
Nobody uses gnustep-gui in a commercial environment and this is a major 
problem (and IMHO the reason why GNUstep is FAR behind KDE and GNOME in 
usability terms). This is not that much a monetary issue, but more the 
customers force requiring the company to provide a working solution.


OK, now what I think GNUstep should be. IMHO the GUI thing should be 
dropped altogether. Really !! (I know I'm going to get killed ;-)

Why ? Because they are definitly not enough resources and there are 
working (and implemented) solutions available for any platform. Some 
points which may might clear why I think so, totally unorganized in note 
form.

- There are about five, maybe ten developers activly working on 
gnustep-gui, but in less than part time. I claim that this *obviously* 
isn't enough to write a complete and production quality GUI framework 
(even in 10 more years).
Think about it, really ! Take a look what KDE does, how long it took and 
how many resources were required to reach the current state. Note that 
Qt is available in stable form for years.

- I agree that the GNUstep GUI framework is almost complete from a 
functional point of view. But now the last 10% of fixing the bugs starts 
and this 10% take 90% of the development time (eg writing the NGImap4 
client library according to the spec took about a month, but getting it 
working in sufficient quality took at least a year). Richard asks for 
people submitting bugs, but it should be understood that this is very 
hard and time killing work and needs qualified people.

- GNUstep as a separate, non Cocoa compliant framework IMHO doesn't 
improve development in a huge way in contrast to KDE or GNOME. If 
GNUstep-GUI would be 100% stable and complete it would still be no KDE 
killer. GNUstep's technology is better than KDE's but not that much, KDE 
is good too and just works.

- A gui framework itself isn't enough. KDE/GNOME are not only frameworks 
but also a significant number of applications. And I'm not talking about 
Finger but about Konqueror, Evolution, Gnumeric, KOffice, Kivio, ... I 
think it's a common myth that once gnustep-gui is ready writing apps 
will be trivial, but it's only trivial for trivial applications, even on 
MacOSX and trivial apps are not killer. Those apps shall be developed by 
the five part-timers ?

- A gui framework isn't enough 2. KDE/GNOME are not only frameworks, but 
also component systems. Eg think of embedding Mozilla into Konqueror or 
Nautilus. Think about DCOP IO services. Configuration management. 
Package management. QuickTime (as a media framework, not necessarily as 
an exact replacement).

- As Nicola has pointed out, Renaissance (or something similiar) is 
required for achieving good platform independence. Now you must realize 
that most systems already work that way and are *blaimed* for that 
traditionally ;-) That is, one of the technical features of gnustep-gui 
was seen in InterfaceBuilder, but we (at least some) already realized 
that this isn't really a good solution for the current problem. Eg 
OPENSTEP/NT wasn't that nice because it wasn't really Windows (same 
problem in Swing and Mozilla). GNUstep-GUI does not have up to date 
abstractions for X-platform GUI.

- I know quite a lot of former NeXT users. Some of them moved to 
Windows, some to Linux and most to MacOSX. Know what ? Nobody is really 
interested in a NeXTstep looking GUI anymore ! Certainly, any NeXT user 
will look at GNUstep and say "wow, cool", but nobody will actually want 
to use it, because UI technology has evolved. MacOSX UI is considered 
better than NeXTstep and XP UI is considered better than NeXTstep (talk 
with someone who uses VisualStudio.NET !).

- GNUstep-GUI might get significant attention if the goal would be to 
reproduce MacOSX completly. Pretty much comparable to WINE at a higher 
level. But this is even a bigger project impossible using existing 
resources.

If I think another day about the topic, I would probably come up with 
more reasons. I know that those a pretty aggressive points, but IMHO 
gnustep-gui can only lead into nothing. It might be a fun project, but 
anyone who actually wants to accomplish something useable for more 
people should think about the points above.


So what would I suggest as a GNUstep goal ?
I have no ready made answer on that, again only some thoughts ;-)

First I think we should focus on GNUstep's real advantages. I see two 
things which are worth a project:
a) Objective-C (and Foundation)
b) gstep-web

I have some difficulties explaining that in email, but I give it a try ;-)

a) IMHO the real advantage is Objective-C. It's simply the better Java 
and the better C#. IMHO the biggest advantage of ObjC is it's 100% 
integration with C (to the level of toll free bridging as seen in 
CoreFoundation).
A difference between GNOME and KDE is, that GNOME tries to be compatible 
with any language at very low level and KDE is C++ only. That results in 
GNOME libraries being written in ANSI-C which is why GNOME is even more 
difficult to develop than KDE. Now the nice thing is, because ObjC is so 
compatible with ANSI-C, we can add "toll-free" additional value. It's 
very easy to wrap anything available in C and make it more usable. We 
can integrate with Apache, we can integrate with Java, with Mono, with 
GNOME, with TCL, with Perl, with Windows, ...

Objective-C is the better C and instead of writing everything from 
scratch we should use that advantage and become a "value-adding" product 
for existing stuff. Pretty much like scripting languages, only on a 
different level.
It's certainly a project that looks very doable to write a very good and 
complete Objective-C wrapper for Gnome or KDE in, say 3 months using 5 
people.
If that would be done, 5 people could finally start out writing 
applications in Objective-C ! The model layer could be easily shared 
between OSX and Linux applications. And we can write good GNOME 
applications in ObjC much faster than other people in plain C.
So we are not winning by base technology, but by superior applications.

Objective-C has an abstraction level almost comparable to Smalltalk or 
Python but by being pragmatic, is a lot faster and more integration 
friendly than those two.

b) It IMHO has less potential than the above, but at least the project 
can in my opinion be completed using the given resources (from 
experience since we have done exactly the same ;-)
This is also pretty much the same way Python got major attention - by 
Zope. We can certainly be far better than Zope basing on WebObjects 
technology. We can provide much better integration with existing 
environments than Zope. And we can be a lot faster.
Also Mono is trying to accomplish that using ASP.NET, which is not 
nearly as usable as WO technology.

But such a project also still needs *quite* some work to make it 
interesting for masses. Eg we would need an IDE for gstep-web (... 
probably somebody needs to write an Eclipse plugin ;-) And we would need 
to support writing components in Java, PHP, Mono, ...


So, that's it what I have in mind till now ;-) I'm open to discuss the 
points and to try to explain further. Please don't flame, be 
constructive ;-)

Greetings
  Helge