Richard Frith-Macdonald: Main developer for the base library, I've also done a lot of work on other parts of the GNUstep system ... infrastructure (library) programming rather than applications (with the exception of Gorm). I am mostly working on software maintenance, improving documentation, and optimising the base library for performance (it already compares well with the Apple Foundation library).
Alexander Malmberg: I'm just another core developer: I fix bugs and implement missing things all over the project. My major isolated contributions are my work on the freetype/libart based backend, back-art, and the implementation of the text system, which is what I'm currently working on. In the GNUstep "project" at large, I've also written several applications and tools, most importantly Terminal (a terminal emulator) [1] and LuserNET (a newsreader) [2].
Ludovic Marcotte: I am on of the developers on the project mainly on the GNUMail.app application [3] (which is part of the GNUstep project). I also work on other application such as Affiche and PlopFolio as well as on an application framework allowing the complete management of email: Pantomime. Presently, I am finalising the next GNUMail.app version and Pantomime. This version will have several functional improvements , its stability as well as overal application performance.
Richard Frith-Macdonald: This was largely a move away from C++, which was much too inflexible for building large real-life (ie constantly changing specifications) projects. ObjC allowed me to build software much more rapidly than C++, and I liked NeXTstep, but couldn't afford to roll out NeXTstep on customer systems, so GNustep was an obvious choice. I particularly liked (and like) the simplicity and power of the distributed objects system ... it let me easily develop highly distributed systems sharing load over many machines.
Alexander Malmberg: Because objective-c is a wonderful language, and GNUstep is a wonderful system built on it. :) I had heard good things about NeXTSTEP and OPENSTEP from many sources for a long time, and I knew that GNUstep was a free implementation of it. Eventually I got around to having a closer look at it, and I really liked what I saw.
Richard Frith-Macdonald: GNUstep has the advantage that it is based on the OpenStep API ... a design which was produced, implemented, and polished by some highly talented people at NeXT, then cleaned up in the light of experience and with a fresh viewpoint provided by the people at Sun. As a result, we have a strongly object-oriented and much more consistent API which is both proven and combines power/flexibility with simplicity. It is therefore much easier to learn to use effectively.
Richard Frith-Macdonald:
It has something for everyone -
Rock-solid 24*7 backend server type applications with distributed messaging.
I've been using the make package, base library, and java bridge (jigs) for this
purpose for some years.
Generally usable gui applications, with inter-application services and other cool
features.
Cutting edge features like object oriented database access and automated gui
layout features in advanced development.
Alexander Malmberg: Most things work. There are still many issues that still need to be sorted out, and there are many minor bugs and annoyances. It's good enough to use and develop for, but if you do, you should be prepared to fix bugs in the core libraries as you find them.
Alexander Malmberg: GNUstep's rendering system is very similar to OPENSTEP's; both use the Display PostScript rendering model, and they have the same api to it. This api is used by the GNUstep's AppKit implementation and applications both when displaying on the screen and when printing. All actual rendering is done by a backend. There are several backends available, with varying capabilities and requirements, and implementing. For example, there is backend for X using xlib, or for X using the X server's native DPS support (a rare thing), or for Win32. back-art implements large parts of the DPS and provides fast and pretty rendering to buffers in general; it can be used with great success when running X locally. There has also been experimental work on backends based on OpenGL and DirectFB.
Alexander Malmberg:
To save developers from having to reinvent the wheel, GNUstep has a very
powerful and extensible text system. Behind each visible text view is a
network of supporting objects.
At the bottom, there's a text storage object that stores Unicode text
and attributes (like font and color).
Above it is a "layout manager". It stores glyphs generated from the
Unicode text and layout information for the glyphs. Glyphs are laid out
in text containers. Normally, there's only one infinitely large,
rectangular container that the user scrolls around in, but multi-page or
multi-column layouts can be done by using several small containers. By
changing the shapes of the containers, text can be made to flow around
eg. pictures.
The actual layout of glyphs is done by a "typesetter". The typesetter
interprets the attributes of the text, looks at the text containers, and
determines where glyphs should be placed. The current default typesetter
does standard left-to-right layout (including things like ligatures and
automatic kerning), but by substituting a different typesetter, vertical
layouts and other advanced script features can be handled
Normally, though, all the complexity is hidden from the developer:
creating a word processor is (almost :) ) as easy as putting a text view
in a window.
Ludovic Marcotte: Firstly, you must understand that GNUstep is a project that is now following the trail of Apple with Cocoa. Because of this, certain classes present in Cocoa do not actually have a GNUstep implementation (such as NSToolbar, NSDrawer classes as well as all the services provided by CoreFoundation). A developer wanting to port a Mac OS X application to GNUstep must note these particularities. You can compensate for these problems by using conditional compilation or even implementing the missing classes and contributing them to the GNUstep project! In other respects, the develop must in general redo the user interfaces if he wants to port his GNUstep application to Osx (or vise-versa). Under GNUstep, GORM is the tool of choice for building user interfaces while under OSX, you need to use Interface Builder. The Rennaissance project may in the future make this difference unnecessary.
Ludovic Marcotte: GNUstep will definitely be an alternative to consider for multi-platform software. Althought Qt and Java already allow complex application development running under Windows, Mac OS X and Linux (or other variants of UNIX) GNUstep has the advantage of the Objective-C language as well as a light weight and efficient application framework (OpenStep).
Richard Frith-Macdonald: Windows...is underway. base and make compile and work; as for the AppKit, it is really alpha. As for the bridges to other languages, Java works really well. The Ruby bridge is good as well. Python is slightly broken actually and could need some volunteers. (The bridge towards Python also works on the MacOS X platform). Guile 1.4 also works, but could need an update to the 1.6 version of guile. There also exists a scripting framework [4] with which you can add the languages you want.
Richard Frith-Macdonald: GNUstep and Apple/Cocoa share the OpenStep roots. GNUstep also implements many Apple additions (though not those specific to some apple technologies) but maintains the NeXTstep look. For many purposes the two systems are source-code compatible.
Alexander Malmberg: As far as I can tell, Apple is simply ignoring GNUstep. The GNUstep community is somewhat divided, but for the most part, GNUstep tries to be compatible with both OPENSTEP and sane Apple extensions.
Alexander Malmberg: The first step is to finish the core libraries (stable interfaces and behavior and complete implementations). Once that's done, we'll have a wonderful set of libraries we can build eg. applications from. What happens then is a bit outside GNUstep's scope, but there are people working on building larger things of it, eg. LinuxSTEP [5].